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

Đáp án

C — Đưa phần mở và đóng kết nối ra ngoài hàm xử lý

Vì sao đúng

Mã khởi tạo nằm ngoài hàm xử lý chỉ chạy một lần cho mỗi môi trường thực thi, còn phần bên trong chạy lại ở mọi lần gọi. Mở kết nối bên trong nghĩa là mỗi lần gọi lại bắt tay với CSDL một lần — với hàng trăm lần mỗi giờ thì RDS nhanh chóng cạn số kết nối. Đưa ra ngoài thì các lần gọi trên cùng một môi trường dùng lại kết nối đã có, số kết nối giảm mạnh và độ trễ cũng giảm theo.

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

• A. Tăng reserved concurrency — cho phép nhiều bản sao chạy song song hơn, tức là mở thêm kết nối; làm vấn đề nặng thêm.
• B. Nâng cỡ CSDL — mua thêm chỗ cho một cách dùng sai; đắt và không chữa gốc.
• D. Đổi sang DynamoDB — thay hẳn CSDL để tránh một lỗi lập trình.

Ghi chú

Với ứng dụng không máy chủ ở quy mô lớn, bước tiếp theo thường là dùng RDS Proxy để gộp và tái dùng kết nối ở tầng riêng.

Đáp án

D — Dùng alias trỏ vào phiên bản hiện tại; publish phiên bản mới và cấu hình alias gửi 10% người dùng sang bản mới; hỏng thì đặt trọng số về 0.

Vì sao đúng

Ba yêu cầu, và weighted alias của Lambda đáp ứng cả ba:

# Publish phiên bản mới
aws lambda publish-version --function-name xu-ly
# Alias 'prod' vẫn trỏ chính vào version 1, thêm 10% sang version 2
aws lambda update-alias --function-name xu-ly --name prod \
  --function-version 1 --routing-config AdditionalVersionWeights={"2"=0.1}
# Rollback: bỏ hẳn trọng số
aws lambda update-alias --function-name xu-ly --name prod \
  --function-version 1 --routing-config '{}'

Điểm hay: bên gọi không biết gì cả. Chúng vẫn gọi cùng một ARN alias; việc chia traffic diễn ra bên trong Lambda.

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

• A. Alias trỏ toàn bộ người dùng sang bản mới — đây là bẫy sát nhất, khác D đúng một chữ. Nó là deploy 100% cùng lúc, nên mọi người dùng gặp lỗi nếu bản mới hỏng. Đề nói rõ chỉ muốn "a certain portion of the traffic".
• B. Deploy thẳng version mới, hỏng thì đổi lại ARN có số phiên bản — không dùng alias, nên mọi bên gọi phải sửa ARN ở cả hai chiều đi và về. Đó chính là thứ alias sinh ra để tránh, và nó gây gián đoạn thật.
• C. "Nhiều alias, alias mới trỏ vào alias hiện tại" — alias không trỏ vào alias khác được. Alias chỉ trỏ vào version. Cấu trúc mô tả trong phương án không tồn tại.

Ghi nhớ

Vài ràng buộc của weighted alias: chỉ chia được giữa hai version, và không trỏ vào $LATEST được. Muốn tự động hoá cả việc rollback theo alarm thì dùng SAM DeploymentPreference với CodeDeploy.

Đáp án

B — AWS cần khoảng 5 tuần dữ liệu sử dụng để sinh ra dự báo ngân sách.

Vì sao đúng

Chi tiết quyết định trong đề: tài khoản mới lập được khoảng ba tuần, và budget được cấu hình theo kiểu forecast-based (cảnh báo khi dự báo sẽ vượt ngưỡng).

Dự báo không phải phép ngoại suy đơn giản — nó là mô hình cần đủ dữ liệu lịch sử để nhận ra xu hướng và tính chu kỳ. AWS ghi rõ yêu cầu: khoảng 5 tuần dữ liệu sử dụng trước khi bắt đầu sinh dự báo.

Tài khoản mới ba tuần thì chưa có dự báo nào để so với ngưỡng, nên cảnh báo forecast-based không bao giờ kích hoạt — không phải vì cấu hình sai, mà vì chưa đủ dữ liệu.

Cách chữa trong lúc chờ: chuyển sang cảnh báo dựa trên chi phí thực tế (actual) thay vì dự báo — loại này hoạt động ngay từ ngày đầu:

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

• A. Tài khoản tạo budget không đủ quyền — thiếu quyền thì việc tạo budget đã thất bại ngay với lỗi AccessDenied. Đề nói rõ budget đã được tạo.
• C. "Phải thuộc AWS Organizations mới nhận được cảnh báo" — sai. AWS Budgets hoạt động ở tài khoản độc lập. Organizations chỉ cần khi muốn quản lý ngân sách tập trung cho nhiều tài khoản.
• D. "CloudWatch có thể đang gặp sự cố" — cực kỳ khó xảy ra trong ba tuần liên tục, và AWS Budgets có cơ chế thông báo riêng qua SNS chứ không phụ thuộc vào một alarm CloudWatch. Đây là kiểu suy đoán không kiểm chứng được.

Ghi nhớ

Vài con số và giới hạn đáng nhớ của AWS Budgets:

• ~5 tuần dữ liệu cho dự báo
• 2 budget đầu tiên miễn phí, sau đó tính phí theo từng budget mỗi ngày
• Dữ liệu chi phí cập nhật khoảng 3 lần mỗi ngày, nên cảnh báo không tức thời
• Có bốn loại budget: cost, usage, reservation, Savings Plans

Với tài khoản mới, hãy dùng cảnh báo actual cho tới khi tích đủ lịch sử.

Đáp án

A — Dùng tham số --region.

Vì sao đúng

Đây là giải pháp tối ưu vì nó không thay đổi bất cứ trạng thái nào:

aws ec2 stop-instances --instance-ids i-1234567890abcdef0 --region us-east-2

Tham số --region ghi đè cấu hình mặc định cho đúng một lệnh. Lệnh tiếp theo vẫn dùng us-east-1 như bình thường.

AWS CLI phân giải Region theo thứ tự ưu tiên:

Đề cũng nói rõ IAM user đã có quyền ở mọi Region, nên không có rào cản phân quyền nào.

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

• C. Chạy lại aws configure để đổi Region mặc định — làm được nhưng kém tối ưu: nó đổi vĩnh viễn cấu hình cho mọi lệnh sau đó. Chạy một lệnh ở Region khác rồi quên đổi lại là nguồn của rất nhiều sự cố "tại sao tài nguyên của tôi ở sai Region". (Nếu thường xuyên làm việc với nhiều Region, cách sạch hơn là tạo profile riêng và dùng --profile.)
• B. Tạo IAM user mới cho Region đó — hiểu sai bản chất IAM: IAM là dịch vụ toàn cầu. Một IAM user hoạt động ở mọi Region; không có khái niệm "user của Region này". Đề còn nói rõ user đã có quyền ở mọi Region.
• D. "boto3 dependency injection" — vô nghĩa trong ngữ cảnh này. boto3 là SDK Python, không phải AWS CLI; và "dependency injection" là một mẫu thiết kế phần mềm, không phải cơ chế chọn Region. Trong boto3, Region được khai bằng boto3.client('ec2', region_name='us-east-2').

Ghi nhớ

Ba cờ ghi đè hữu ích nhất của AWS CLI, dùng cho từng lệnh:

aws <lenh> --region us-east-2       # đổi Region
aws <lenh> --profile production     # đổi bộ thông tin xác thực
aws <lenh> --output json            # đổi định dạng đầu ra

Nguyên tắc chung: ưu tiên ghi đè theo từng lệnh hơn là đổi cấu hình toàn cục — ít tác dụng phụ, không cần nhớ đổi lại.

Đáp án

A — CloudFront Key Pair chỉ tạo được bởi tài khoản root.

Vì sao đúng

CloudFront key pair là bộ khoá dùng để ký URL và cookie cho nội dung riêng tư (signed URL / signed cookie). Nó là một trong số rất ít loại thông tin xác thực mà AWS gắn cứng với root user:

• Chỉ root user tạo được (IAM user, kể cả admin, cũng không tạo được)
• Được quản lý ở trang Security Credentials của tài khoản root
• Tối đa hai key pair đang hoạt động cùng lúc

Đây chính là lý do AWS về sau giới thiệu CloudFront trusted key groups — cơ chế thay thế cho phép IAM user quản lý khoá công khai, không phải đăng nhập root. Với thiết kế mới thì nên dùng key group; nhưng câu hỏi về key pair vẫn còn trong đề thi vì nó là ví dụ điển hình của "thao tác chỉ root làm được".

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

• B. IAM user access key — bất kỳ principal nào có quyền iam:CreateAccessKey đều tạo được, cho chính mình hoặc cho user khác.
• C. Mật khẩu của IAM user — tạo bằng iam:CreateLoginProfile, quyền IAM thông thường.
• D. EC2 instance key pair — tạo bằng ec2:CreateKeyPair hoặc import khoá công khai của bạn. Hoàn toàn là quyền IAM thông thường, và mỗi Region có bộ key pair riêng.

Ghi nhớ

Những thao tác chỉ root user làm được — danh sách đáng thuộc: | Thao tác | |---| | Tạo CloudFront key pair | | Đổi tên tài khoản, email, mật khẩu root | | Đóng tài khoản AWS | | Đổi gói hỗ trợ (Support plan) | | Khôi phục quyền khi IAM policy bị khoá nhầm | | Bật MFA Delete cho bucket S3 | | Đăng ký làm người bán trên Marketplace | | Rời khỏi một AWS Organization |

Nguyên tắc vận hành: dùng root đúng những việc trên rồi thôi. Bật MFA cho root, cất thông tin đăng nhập an toàn, và làm mọi việc hằng ngày bằng IAM.

Đáp án

C — Dependencies không phải là một section hợp lệ của template CloudFormation.

Vì sao đúng

Template CloudFormation có một tập section cố định, và Dependencies không nằm trong đó:

Vậy quan hệ phụ thuộc khai ở đâu? Có hai cách, và cả hai đều nằm bên trong Resources:

1. Ngầm định — dùng !Ref hoặc !GetAtt là CloudFormation tự suy ra thứ tự:

MayChu:
  Type: AWS::EC2::Instance
  Properties:
    SubnetId: !Ref SubnetChinh     # tự biết phải tạo subnet trước

2. Tường minh — thuộc tính DependsOn khi không có tham chiếu nào để suy ra:

MayChu:
  Type: AWS::EC2::Instance
  DependsOn: DinhTuyenInternet

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

• A. Resources — section duy nhất bắt buộc của mọi template.
• B. Conditions — hợp lệ, dùng để tạo tài nguyên có điều kiện (ví dụ chỉ tạo bản sao lưu ở môi trường production).
• D. Parameters — hợp lệ, dùng để nhận giá trị lúc deploy.

Ghi nhớ

Nhớ điểm khác biệt cốt lõi: DependsOn là một THUỘC TÍNH của tài nguyên, không phải một SECTION của template. Và trong thực tế, hãy ưu tiên để CloudFormation tự suy ra thứ tự qua !Ref/!GetAtt — dùng DependsOn thủ công quá nhiều sẽ tuần tự hoá việc tạo tài nguyên và làm stack chậm hẳn.

Đáp án

A — IAM Access Analyzer.

Vì sao đúng

Yêu cầu: tìm IAM role không được dùng và gỡ chúng mà không làm gián đoạn dịch vụ nào.

IAM Access Analyzer có tính năng unused access analyzer, sinh ra đúng cho việc này:

Mục cuối cùng là mục giá trị nhất cho tình huống trong đề: nó không chỉ nói "role này không ai dùng", mà còn nói "role này có 40 quyền nhưng chỉ 5 quyền từng được sử dụng", và sinh sẵn policy tối thiểu dựa trên lịch sử CloudTrail.

Vế "không gây gián đoạn" cũng được đảm bảo: dữ liệu dựa trên hoạt động thật trong khoảng thời gian bạn chọn, nên bạn biết chính xác cái gì đang được dùng trước khi gỡ.

Access Analyzer còn một tính năng thứ hai đáng nhớ: external access analyzer, phát hiện tài nguyên (S3 bucket, KMS key, role…) đang được chia sẻ ra ngoài tài khoản hoặc ngoài tổ chức.

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

• B. AWS Security Hub — gom và chuẩn hoá phát hiện bảo mật từ GuardDuty, Inspector, Macie, Config và bên thứ ba, chấm theo các khung chuẩn (CIS, PCI DSS). Nó không phân tích việc sử dụng IAM role.
• C. Amazon Inspector — quét lỗ hổng phần mềm trên EC2, container image, Lambda. Không đụng gì tới IAM.
• D. AWS Trusted Advisor — có một số check IAM (ví dụ cảnh báo access key lộ ra công khai, hoặc thiếu MFA cho root), nhưng không có phân tích quyền chưa dùng và không sinh policy tối thiểu. Nó cũng làm mới chậm và các check bảo mật đầy đủ đòi gói Business trở lên.

Ghi nhớ

Bộ công cụ thu hẹp quyền IAM, dùng kết hợp: | Công cụ | Cho biết | |---|---| | Access Analyzer — unused access | role/khoá/quyền nào chưa từng dùng | | Access Analyzer — policy generation | sinh policy tối thiểu từ lịch sử CloudTrail | | Access Analyzer — external access | tài nguyên đang chia sẻ ra ngoài | | IAM Last Accessed (trong Console) | dịch vụ nào đã được truy cập lần cuối khi nào |

Quy trình thu hẹp quyền an toàn: đo bằng Access Analyzer → sinh policy tối thiểu → áp ở môi trường thấp trước → theo dõi CloudTrail → mới áp production.

Đáp án

C — Triển khai bằng chính sách "Rolling with additional batch".

Vì sao đúng

Ba yêu cầu: lưu lượng cao, không suy giảm hiệu năng hay tính sẵn sàng, và tiết kiệm chi phí.

So sánh bốn chính sách của Elastic Beanstalk:

Rolling with additional batch hoạt động thế này: dựng thêm một lô instance mới trước, rồi mới bắt đầu thay thế theo lô. Nhờ lô dư đó, năng lực phục vụ không bao giờ tụt xuống dưới 100% — đúng yêu cầu "high traffic, không suy giảm hiệu năng".

Và nó rẻ hơn Immutable rõ rệt: chỉ trả thêm cho một lô (ví dụ 25% fleet), thay vì nhân đôi toàn bộ.

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

• A. Rolling thuần — trong lúc một lô đang được cập nhật, năng lực còn lại giảm xuống. Với ứng dụng lưu lượng cao, đó chính là suy giảm hiệu năng mà đề cấm.
• B. All at once — có thời gian chết. Loại ngay với yêu cầu tính sẵn sàng cao.
• D. Immutable — đáp ứng đầy đủ về hiệu năng và an toàn (dựng fleet mới hoàn toàn, hỏng thì huỷ), nhưng tốn gấp đôi hạ tầng trong suốt quá trình deploy và chậm hơn hẳn. Đề nói rõ "keeping the solution cost-effective", nên nó thua C.

Ghi nhớ

Cách chọn nhanh chính sách deploy của Beanstalk: | Ưu tiên | Chọn | |---|---| | Rẻ nhất, chấp nhận thời gian chết | All at once | | Không thời gian chết, không tốn thêm | Rolling | | Không giảm năng lực, chi phí thêm tối thiểu | Rolling with additional batch | | An toàn nhất, chấp nhận tốn gấp đôi | Immutable | | Rollback tức thì | Blue/Green (swap CNAME) |

Chỉ Blue/Green cho rollback tức thì, vì môi trường cũ vẫn còn nguyên.

Đáp án

B và D.

• B — Dựng được hệ thống có tính sẵn sàng cao.
• D — Tách lưu lượng công khai khỏi lưu lượng nội bộ.

Vì sao đúng

Hai đặc điểm này là giá trị cốt lõi của Elastic Load Balancing:

B — tính sẵn sàng cao. ELB liên tục chạy health check và chỉ gửi traffic tới target lành. Nó cũng phân phối trên nhiều AZ, nên một AZ sập thì lưu lượng tự dồn sang AZ còn lại mà không ai phải can thiệp.

D — tách lưu lượng. Đây là mẫu kiến trúc chuẩn của AWS:

Internet → ALB công khai (public subnet)
              ↓
         EC2 tầng web (private subnet)
              ↓
         ALB nội bộ (internal)
              ↓
         EC2 tầng ứng dụng (private subnet)
              ↓
         RDS (private subnet)

ELB có hai kiểu: internet-facing (có IP công khai) và internal (chỉ IP riêng). Nhờ vậy instance không cần IP công khai — chúng nằm hoàn toàn trong subnet riêng, và ELB là điểm vào duy nhất.

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

• A. "Load balancer liên lạc với EC2 bằng IP công khai" — sai hẳn. ELB dùng IP riêng của instance trong VPC. Đây chính là lý do instance đứng sau ELB không cần IP công khai — và đó là điểm cộng về bảo mật, không phải điểm trừ.
• C. "Triển khai EC2 trên nhiều AWS Region" — ELB là dịch vụ theo Region. Một load balancer không phân phối traffic xuyên Region. Muốn cân bằng đa Region thì dùng Route 53 (latency/geoproximity routing) hoặc AWS Global Accelerator.
• E. "Cải thiện khả năng mở rộng theo chiều dọc" — nhầm hai khái niệm. Vertical scaling là làm một máy mạnh hơn (nhiều CPU/RAM hơn); ELB không làm điều đó. ELB hỗ trợ horizontal scaling — thêm nhiều máy và chia tải giữa chúng.

Ghi nhớ

Và phân biệt: vertical scaling = máy to hơn; horizontal scaling = nhiều máy hơn — ELB thuộc vế thứ hai.

Đáp án

B — Dedicated Instances.

Vì sao đúng

Yêu cầu: chạy trên phần cứng dành riêng cho một khách hàng (single-tenant), với chi phí thấp nhất.

AWS có hai mô hình tenancy dành riêng, và khác biệt giữa chúng là toàn bộ nội dung câu hỏi:

Với yêu cầu chỉ cần cô lập phần cứng để tuân thủ hướng dẫn bảo mật — không cần BYOL, không cần thấy topology vật lý — thì Dedicated Instances rẻ hơn vì bạn chỉ trả cho số instance thực dùng, không phải bao trọn cả một máy chủ.

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

• C. Dedicated Hosts — thoả yêu cầu cô lập nhưng đắt hơn: bạn trả tiền cho toàn bộ máy chủ vật lý, kể cả phần năng lực không dùng tới. Chỉ đáng khi cần BYOL theo core (Windows Server, Oracle, SQL Server) hoặc cần chứng minh vị trí vật lý cho kiểm toán.
• A. Spot Instances — chạy trên phần cứng dùng chung (shared tenancy), không cô lập gì cả. Và Spot có thể bị thu hồi bất cứ lúc nào, không phù hợp cho ứng dụng của một công ty an ninh mạng.
• D. On-Demand Instances — mặc định là shared tenancy. Rẻ hơn Dedicated Instances thật, nhưng không đáp ứng yêu cầu single-tenant — mà đó là điều kiện bắt buộc, không phải tuỳ chọn.

Ghi nhớ

Bốn mô hình tenancy của EC2: | Tenancy | Phần cứng | |---|---| | default (shared) | dùng chung với khách hàng khác | | dedicated | máy chủ vật lý riêng, trả theo instance | | host | máy chủ vật lý riêng, trả theo máy chủ |

Cách chọn nhanh: cần cô lập thôi ⇒ Dedicated Instances. Cần thêm BYOL theo core hoặc kiểm soát vị trí vật lý ⇒ Dedicated Hosts.