Ngân hàng đề — AWS Certified DevOps Engineer Professional

Đáp án

A — Cài CloudWatch Agent với plugin procstat để giám sát tiến trình và phát metric; dùng Systems Manager Run Command để khởi động lại tiến trình bị hỏng.

Vì sao đúng

Hai ràng buộc định hình đáp án: khắc phục nhanh và không ảnh hưởng dung lượng của Auto Scaling group.

Vế phát hiện. Plugin procstat của CloudWatch Agent theo dõi tiến trình cụ thể và phát metric như procstat_lookup_pid_count:

{"metrics": {"metrics_collected": {"procstat": [
  {"exe": "ung-dung-java", "measurement": ["pid_count", "cpu_usage", "memory_rss"]}
]}}}

Metric về 0 nghĩa là tiến trình chết. Alarm bắt việc đó.

Vế khắc phục — và đây là điểm quyết định. Vấn đề chỉ là một tiến trình cần khởi động lại, không phải cả máy hỏng. Run Command chạy đúng một lệnh trên đúng máy đó:

aws ssm send-command --document-name "AWS-RunShellScript" \
  --targets "Key=InstanceIds,Values=i-xxxx" \
  --parameters 'commands=["systemctl restart ung-dung"]'

Instance vẫn nằm trong ASG, vẫn tính vào dung lượng, không bị thay thế — đúng yêu cầu.

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

• B. EventBridge 10 phút, Lambda lần lượt gỡ và khởi động lại từng instance — khởi động lại mọi instance cứ mỗi 10 phút, kể cả những máy hoàn toàn khoẻ. Gây gián đoạn liên tục và có làm giảm dung lượng trong lúc máy đang khởi động lại.
• C. Cron trên máy + set-instance-health và D. Lambda + set-instance-health — cùng một lỗi cốt lõi: đánh dấu instance là Unhealthy khiến ASG huỷ nó và tạo máy mới. Trong khoảng thời gian đó dung lượng bị giảm, trái thẳng yêu cầu. Đây là dùng búa tạ (thay cả máy) cho việc chỉ cần khởi động lại một tiến trình. C còn thêm nhược điểm: cron chạy trên chính máy có thể đang trục trặc.

Ghi nhớ

Chọn mức can thiệp tương xứng với sự cố: | Sự cố | Cách xử lý | |---|---| | Một tiến trình chết | procstat + Run Command khởi động lại | | Máy hỏng thật sự | set-instance-health Unhealthy → ASG thay máy | | Cả một AZ hỏng | ASG tự cân bằng sang AZ khác |

Và nhớ: set-instance-health luôn dẫn tới thay thế instance, nên nó không bao giờ là đáp án khi đề nói "không được ảnh hưởng dung lượng".

Đáp án theo nguồn

C, D và E — trong đó chỉ C và D là đúng, xem phần ghi chú cuối bài.

• D — Tạo lifecycle hook cho hành động terminate, EventBridge gọi Lambda dùng SSM Run Command trích xuất log và lưu vào S3.
• C — Phân tích log trực tiếp trên S3 bằng Amazon Athena.

Vì sao đúng

Thông báo lỗi trong đề — "Lifecycle Action ... was abandoned: Heartbeat Timeout" — cho biết đã có sẵn một lifecycle hook nhưng không ai gọi CompleteLifecycleAction trước khi hết giờ chờ.

Nhưng câu hỏi không hỏi cách sửa lỗi đó. Nó hỏi: làm sao thu log của các instance bị ảnh hưởng trước khi chúng biến mất.

Vế thu log (D). Đây là bài toán kinh điển: instance bị huỷ thì ổ đĩa và log cục bộ biến mất theo. Lifecycle hook cho TERMINATING giữ instance lại ở trạng thái Terminating:Wait (mặc định 1 giờ), đủ thời gian để Run Command vào lấy log đẩy lên S3 — rồi mới thả cho ASG huỷ.

Vế phân tích (C). Log đã nằm trên S3 thì Athena truy vấn thẳng bằng SQL: serverless, không cụm nào phải dựng, trả tiền theo dữ liệu quét.

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

• A. Sửa health check cho đúng cổng và giao thức — có thể là cách chữa nguyên nhân gốc, nhưng không thu được log nào. Ngoài phạm vi câu hỏi.
• B. Nạp log vào cụm Amazon EMR — làm được nhưng đắt và nặng: phải dựng và nuôi cụm. Với việc đọc log dạng văn bản, Athena rẻ hơn nhiều lần và không có gì để quản.
• F. Bật access log "ở mức Target Group" — không tồn tại. Access log bật ở mức load balancer, không phải target group. Và kể cả có, access log của ALB chỉ ghi request HTTP đi qua, không chứa log ứng dụng trên instance.

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

Phương án E — "Update the deployment group as the AWS CodeDeploy limits have been reached" — bị nguồn đánh dấu là đáp án đúng, nhưng nó không thể đúng. Đề không nhắc tới CodeDeploy ở bất kỳ đâu, thông báo lỗi là của Auto Scaling lifecycle hook chứ không phải của CodeDeploy, và bản thân phương án không thu thập hay lưu trữ log nào — tức là không trả lời câu hỏi được đặt ra.

Nhiều khả năng đề gốc là (Select TWO) với đáp án C và D, và phương án E bị gán nhầm khi số hoá. Hãy học theo C và D; E ghi ở đây chỉ để bạn biết khoá đáp án của nguồn ghi gì, không phải để ghi nhớ.

Đáp án

C — Ứng dụng đẩy sự kiện vào SNS topic; Lambda đăng ký topic, xử lý và ghi kết quả vào DynamoDB.

Vì sao đúng

Đề có ba từ khoá, và mỗi từ chốt một thành phần:

Vế cuối là vế phân biệt rõ nhất. DynamoDB là kho khoá/giá trị serverless — không có instance nào, trả tiền theo dung lượng dùng, tự co giãn.

SNS đẩy trực tiếp sang Lambda, không cần polling. Và mô hình publish/subscribe để ngỏ khả năng thêm người nhận sau này (một hàng đợi lưu trữ, một hệ thống phân tích) mà không phải sửa ứng dụng phát tin.

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

• A. S3 + EventBridge + Athena — Athena là công cụ truy vấn, không phải kho khoá/giá trị và không "xử lý rồi lưu kết quả". Hơn nữa đi qua S3 nghĩa là mỗi sự kiện thành một object — vòng vo và tốn kém cho dữ liệu nhỏ.
• B. SQS + Lambda + ElastiCache — SQS hoàn toàn hợp lý cho phần vận chuyển, nhưng ElastiCache không serverless ở dạng cụm truyền thống: có node, có giờ chạy, có vá. Quan trọng hơn, nó là cache trong bộ nhớ, không phải kho lưu trữ bền vững. Kết quả xử lý mà cất vào cache là chấp nhận mất dữ liệu.
• D. Firehose → S3 → event notification → Lambda — Firehose gom theo lô (theo kích thước hoặc theo thời gian, tối thiểu khoảng 60 giây), nên nó không phải kiến trúc theo từng sự kiện. Đề nói "process for each event". Thêm nữa, đường đi này để dữ liệu vào S3 chứ không vào kho khoá/giá trị.

Ghi nhớ

Ba dịch vụ nhắn tin, đừng lẫn: | | SNS | SQS | EventBridge | |---|---|---|---| | Mô hình | pub/sub, đẩy | hàng đợi, kéo | định tuyến theo mẫu | | Nhiều người nhận | ✅ | ❌ (mỗi message một consumer) | ✅ | | Lọc | filter policy | không | event pattern mạnh | | Hợp khi | fan-out tức thì | đệm tải, xử lý chậm | tích hợp SaaS, sự kiện AWS |

Đáp án

C, D và F.

• F — Tạo IAM role ở tài khoản NGUỒN có quyền trên cả hai bucket.
• D — Tạo replication rule ở bucket NGUỒN.
• C — Thêm statement vào bucket policy của bucket ĐÍCH cho phép role sao chép ghi vào.

Vì sao đúng

Toàn bộ câu này xoay quanh một sự thật: S3 replication là cơ chế ĐẨY, do bucket nguồn khởi xướng.

Từ đó suy ra cả ba mảnh:

Role cần quyền hai đầu:

// Ở nguồn: đọc object và metadata sao chép
{"Action": ["s3:GetObjectVersionForReplication", "s3:GetObjectVersionAcl",
            "s3:ListBucket", "s3:GetReplicationConfiguration"],
 "Resource": ["arn:aws:s3:::nguon", "arn:aws:s3:::nguon/*"]}
// Ở đích: ghi bản sao
{"Action": ["s3:ReplicateObject", "s3:ReplicateDelete", "s3:ReplicateTags"],
 "Resource": "arn:aws:s3:::dich/*"}

Một điều kiện đề không nêu nhưng bắt buộc: cả hai bucket phải bật versioning. Không có versioning thì không cấu hình replication được.

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

• A. Replication rule ở bucket đích — sai chiều. Bucket đích không kéo dữ liệu về; nó chỉ nhận.
• B. Bucket policy ở bucket nguồn — không cần. Role đã nằm trong cùng tài khoản với bucket nguồn, nên identity policy của role là đủ; không cần thêm resource policy cho chính mình.
• E. IAM role ở tài khoản đích — sai tài khoản. S3 assume role ở phía nguồn, vì đó là nơi dịch vụ đọc dữ liệu và phát động việc sao chép.

Ghi nhớ

Với replication chéo tài khoản, thêm hai chi tiết thực tế đáng nhớ: bật ChangeObjectOwnership để tài khoản đích thực sự sở hữu bản sao (nếu không, object thuộc về tài khoản nguồn và bên đích không đọc được), và nhớ rằng replication chỉ áp dụng cho object ghi SAU khi bật rule — muốn chép dữ liệu cũ thì phải dùng S3 Batch Replication.

Đáp án

B — Lưu thông tin đăng nhập trong AWS Secrets Manager; gắn cho Lambda một role có quyền đọc bí mật đó theo secret ID.

Vì sao đúng

Hai yêu cầu, và yêu cầu thứ hai loại hết các lựa chọn còn lại:

1. Không để thông tin xác thực trong mã nguồn
2. Phải xoay vòng định kỳ theo chính sách bảo mật

Secrets Manager là dịch vụ AWS duy nhất có xoay vòng tự động dựng sẵn, và với các CSDL AWS (RDS, Aurora, DocumentDB, Redshift) nó còn có sẵn Lambda xoay vòng — bạn chỉ chọn chu kỳ:

import boto3, json
sm = boto3.client('secretsmanager')
def handler(event, context):
    bi_mat = json.loads(sm.get_secret_value(SecretId='prod/db/creds')['SecretString'])
    ket_noi = tao_ket_noi(bi_mat['username'], bi_mat['password'], bi_mat['host'])

Cơ chế xoay vòng dùng hai bộ thông tin xen kẽ (staging label AWSCURRENT và AWSPENDING), nên trong lúc đổi mật khẩu không có khoảng thời gian nào ứng dụng bị từ chối.

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

• A. AWS CloudHSM — module bảo mật phần cứng để quản lý khoá mã hoá và thực hiện phép mật mã. Nó không phải kho bí mật dạng văn bản, không có xoay vòng thông tin đăng nhập, và đắt hơn nhiều bậc (tính theo giờ HSM).
• C. Biến môi trường của Lambda — có vẻ ổn vì mã sạch, nhưng không xoay vòng được: đổi mật khẩu là phải cập nhật cấu hình hàm và deploy lại. Ngoài ra biến môi trường hiện nguyên văn trong console và trong GetFunctionConfiguration với bất kỳ ai có quyền đọc cấu hình hàm.
• D. AWS KMS — KMS quản lý khoá, không lưu bí mật. Có thể dùng KMS để tự mã hoá mật khẩu rồi cất ở đâu đó, nhưng khi ấy bạn phải tự viết toàn bộ phần xoay vòng — đúng thứ Secrets Manager làm sẵn.

Ghi nhớ

Đề nói "regularly rotated" thì luôn là Secrets Manager. Không có yêu cầu xoay vòng và cần tiết kiệm thì Parameter Store là lựa chọn hợp lý.

Đáp án

A — Amazon MemoryDB for Redis.

Vì sao đúng

Đề nêu bốn yêu cầu, và chúng đồng thời chỉ vào một dịch vụ:

Từ khoá quyết định là "store data durably". MemoryDB là cơ sở dữ liệu chính trong bộ nhớ, không phải cache: mỗi lần ghi được cam kết vào transaction log phân tán trên nhiều AZ trước khi báo thành công. Mất một node, thậm chí mất một AZ, dữ liệu vẫn còn.

Đó cũng là ranh giới phân biệt nó với ElastiCache: ElastiCache là cache, dữ liệu trong đó về nguyên tắc có thể mất và phải dựng lại được từ nguồn khác.

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

• B. ElastiCache for Memcached — sai nhiều nhất: không có tính bền vững (không snapshot, không replica), không có sao chép, mất node là mất sạch dữ liệu trên node đó. Nó là cache thuần tuý.
• D. ElastiCache for Redis — đây là bẫy chính, và khác biệt rất tinh tế. ElastiCache for Redis có replica và có snapshot, nhưng sao chép là bất đồng bộ: failover có thể mất những lần ghi gần nhất. Nó cũng chỉ đảm bảo nhất quán cuối cùng khi đọc từ replica. Đề đòi bền vững và nhất quán mạnh, nên phải là MemoryDB.
• C. Amazon Managed Grafana — không phải cơ sở dữ liệu. Đó là dịch vụ trực quan hoá dữ liệu giám sát. Hoàn toàn lạc chủ đề.

Ghi nhớ

Đáp án

C — EventBridge rule với event pattern "AWS API Call via CloudTrail" bắt lời gọi AssumeRole, gọi Lambda và đẩy thông báo lên SNS.

Vì sao đúng

Việc cần bắt là hành động assume một IAM role, và hành động đó là lời gọi API sts:AssumeRole — được CloudTrail ghi lại và chuyển tiếp lên EventBridge.

{
  "source": ["aws.sts"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["sts.amazonaws.com"],
    "eventName": ["AssumeRole"],
    "requestParameters": {
      "roleArn": ["arn:aws:iam::123456789012:role/Administrator"]
    }
  }
}

Lambda ở đây có ích vì nó dựng được thông báo dễ đọc: ai assume (userIdentity), lúc nào, từ IP nào, roleSessionName là gì. Gửi thẳng JSON thô sang SNS thì đội bảo mật nhận một khối khó đọc.

Một chi tiết vận hành đáng biết: lời gọi AssumeRole được ghi ở Region nơi endpoint STS được gọi. Với STS toàn cầu (endpoint cũ) thì sự kiện xuất hiện ở us-east-1 — nên rule phải đặt đúng chỗ, nếu không nó im lặng không bao giờ khớp.

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

• A. GuardDuty cảnh báo "sử dụng bất thường" — GuardDuty tìm hành vi bất thường, không báo mọi lần dùng role. Việc dùng role admin hợp lệ hằng ngày sẽ không sinh phát hiện nào. Ngoài ra "publish a notification to a CloudTrail trail" là vô nghĩa — CloudTrail là nơi ghi log, không phải đích nhận thông báo.
• B. AWS Config lưu log rồi Athena truy vấn — sai hai tầng. Config theo dõi cấu hình tài nguyên, không ghi sự kiện đăng nhập hay AssumeRole. Và truy vấn định kỳ bằng Athena là theo lô, không phải cảnh báo gần thời gian thực. "Publish a notification to Kinesis Firehose" cũng nhầm vai trò dịch vụ.
• D. Event pattern "AWS Console Sign In via CloudTrail" — đây là bẫy sát nhất. Sự kiện đó bắt việc đăng nhập vào Console bằng danh tính của chính mình, không bắt việc chuyển vai (switch role). Người dùng có thể assume role admin hoàn toàn qua CLI/SDK mà không hề đăng nhập Console — và cách đó sẽ lọt hết.

Ghi nhớ

Ba loại event pattern của CloudTrail trên EventBridge, phân biệt cho rõ: | detail-type | Bắt gì | |---|---| | AWS API Call via CloudTrail | mọi lời gọi API — dùng cho AssumeRole | | AWS Console Sign In via CloudTrail | đăng nhập Console | | AWS Service Event via CloudTrail | sự kiện do chính dịch vụ phát |

Đáp án

A — Tạm dừng tiến trình AddToLoadBalancer.

Vì sao đúng

Yêu cầu rất hẹp: instance mới vào được ASG nhưng chưa nhận traffic, để kiểm thử trước.

AddToLoadBalancer là tiến trình mà Auto Scaling dùng để đăng ký instance mới vào load balancer / target group. Tạm dừng nó thì:

• Instance vẫn được tạo, vẫn thuộc ASG, vẫn tính vào desired capacity
• Nhưng không được đăng ký vào target group, nên không nhận request nào

Kiểm thử xong thì tự đăng ký bằng tay:

aws autoscaling suspend-processes --auto-scaling-group-name nhom-web \
  --scaling-processes AddToLoadBalancer
# ... kiểm thử instance mới ...
aws elbv2 register-targets --target-group-arn <arn> --targets Id=i-xxxx

Lưu ý quan trọng: tạm dừng tiến trình này chỉ ảnh hưởng instance mới. Instance đã đăng ký từ trước vẫn ở nguyên trong target group và vẫn phục vụ bình thường.

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

• B. AZ Rebalance — tiến trình phân bố lại instance cho đều giữa các AZ. Chẳng liên quan gì tới việc đăng ký vào load balancer.
• C. HealthCheck — tạm dừng nó nghĩa là ASG ngừng đánh giá sức khoẻ của mọi instance. Instance mới vẫn được đăng ký vào target group và vẫn nhận traffic — không đạt mục tiêu, mà lại làm mù cả nhóm.
• D. ReplaceUnhealthy — chỉ ngăn ASG thay thế instance bị đánh dấu không lành. Instance mới vẫn vào load balancer như thường.

Ghi nhớ

Các tiến trình tạm dừng được của ASG và tác dụng: | Tiến trình | Tạm dừng thì | |---|---| | AddToLoadBalancer | instance mới không vào target group | | Launch / Terminate | ngừng tạo / ngừng huỷ | | HealthCheck | ngừng đánh giá sức khoẻ | | ReplaceUnhealthy | không thay instance hỏng | | AZRebalance | không cân bằng lại giữa AZ | | AlarmNotification / ScheduledActions | bỏ qua alarm / bỏ qua lịch |

Đáp án

D — Lambda gửi email bằng Amazon SES, gắn vào Cognito bằng post authentication Lambda trigger.

Vì sao đúng

Cognito user pool có sẵn một bộ Lambda trigger móc vào từng mốc trong vòng đời xác thực. Cần gửi thư "mỗi lần người dùng đăng nhập" thì đúng mốc là Post authentication — Cognito gọi nó sau khi xác thực thành công, kèm đầy đủ ngữ cảnh:

def handler(event, context):
    thuoc_tinh = event['request']['userAttributes']
    ses.send_email(
        Source='thongbao@congty.vn',
        Destination={'ToAddresses': [thuoc_tinh['email']]},
        Message={'Subject': {'Data': 'Có phiên đăng nhập mới'},
                 'Body': {'Text': {'Data': f"Tài khoản {event['userName']} vừa đăng nhập."}}})
    return event   # BẮT BUỘC trả lại event, nếu không luồng xác thực hỏng

Vì sao đây là cách hiệu quả nhất về vận hành: không đường ống nào phải dựng, không polling, không log phải quét. Cognito gọi thẳng hàm, đồng bộ, đúng một lần cho mỗi lần đăng nhập thành công.

Một lưu ý thực tế: trigger này chạy đồng bộ trong luồng đăng nhập, nên hàm chậm hoặc lỗi sẽ làm chậm hoặc chặn đăng nhập. Với gửi mail, cách an toàn hơn là đẩy sang SQS/EventBridge rồi trả về ngay.

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

• A. Stream toàn bộ log sang Kinesis Data Firehose rồi lọc — nặng nề: một đường ống chỉ để phát hiện một sự kiện mà Cognito đã sẵn sàng báo trực tiếp. Thêm độ trễ do gom lô, thêm chi phí, thêm chỗ hỏng.
• B. CloudWatch Logs subscription filter — dựa vào việc phân tích văn bản log, tức là phụ thuộc vào định dạng log có thể đổi bất cứ lúc nào mà không báo trước. Trigger là hợp đồng có phiên bản; log thì không.
• C. API Gateway + gọi từ phía client — sai về mặt bảo mật: tin vào client để báo cáo sự kiện đăng nhập. Client sửa được, bỏ qua được, hoặc gọi giả. Sự kiện bảo mật phải được ghi nhận ở phía máy chủ.

Ghi nhớ

Các Lambda trigger đáng nhớ của Cognito user pool: | Trigger | Thời điểm | |---|---| | Pre sign-up | trước khi đăng ký — tự duyệt, chặn tên miền | | Pre authentication | trước khi xác thực — chặn theo điều kiện | | Post authentication | sau khi đăng nhập thành công | | Pre token generation | thêm claim tuỳ biến vào token | | Custom message | tuỳ biến nội dung email/SMS |

Đáp án

C — Dùng AWS Database Migration Service (DMS) để sao chép dữ liệu từ RDS sang Amazon Redshift.

Vì sao đúng

Vấn đề: truy vấn phân tích tự phát đang giành tài nguyên với tải giao dịch trên chính CSDL production. Cách chữa đúng về kiến trúc là tách hẳn tải phân tích sang một hệ riêng — Redshift, kho dữ liệu cột tối ưu cho quét lớn.

DMS là công cụ chuẩn cho đường dẫn đó, và nó có một tính năng quyết định: CDC (Change Data Capture). Sau lần tải đầy đủ, DMS đọc transaction log của Oracle và PostgreSQL để chuyển tiếp liên tục mọi thay đổi:

RDS Oracle     ─┐
                ├─ DMS (full load + CDC) ─→ Redshift ─→ báo cáo hằng ngày
RDS PostgreSQL ─┘

Ba điểm cộng: hỗ trợ sẵn cả Oracle lẫn PostgreSQL làm nguồn và Redshift làm đích, tác động rất nhỏ lên CSDL nguồn (đọc log chứ không quét bảng), và không phải viết mã.

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

• A. Kinesis Data Streams — Kinesis nhận luồng sự kiện được ứng dụng đẩy vào; nó không tự đọc được CSDL quan hệ. Muốn dùng thì vẫn phải có ai đó bắt thay đổi từ CSDL rồi đẩy vào — mà đó chính là việc của DMS.
• B. AWS Glue — Glue làm được việc trích xuất từ JDBC sang Redshift, nhưng nó là ETL chạy theo lô: job chạy theo lịch và quét bảng ở mỗi lần chạy. Quét bảng lớn chính là thứ đang gây quá tải. Glue cũng không có CDC gốc cho Oracle/PostgreSQL như DMS.
• D. Amazon EMR — cụm Spark/Hadoop cho xử lý dữ liệu lớn tuỳ biến. Dùng nó chỉ để sao chép dữ liệu là dựng cả một cụm phải nuôi và phải viết job — nặng hơn hẳn, không được gì thêm.

Ghi nhớ

Cách rẻ hơn cho câu này ngoài đời: nếu tải báo cáo không quá nặng, chỉ cần read replica là đủ tách tải mà không cần kho dữ liệu riêng.