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

Đáp án

A — !GetAtt

Vì sao đúng

Endpoint kết nối của một RDS instance là một thuộc tính của tài nguyên đó, không phải định danh chính của nó — nên hàm cần dùng là GetAtt.

⚠ Điểm mấu chốt: Ref trả về một giá trị duy nhất do AWS định nghĩa cho từng loại tài nguyên — muốn thứ khác thì phải dùng GetAtt:

!Ref cho RDS DBInstance → trả về identifier của instance
        ↓
    Không phải endpoint
        ↓
!GetAtt MyDB.Endpoint.Address → trả về tên máy chủ để kết nối
!GetAtt MyDB.Endpoint.Port    → trả về cổng

Outputs:
  DiaChiCSDL:
    Value: !GetAtt CoSoDuLieu.Endpoint.Address
  CongCSDL:
    Value: !GetAtt CoSoDuLieu.Endpoint.Port

⚠ Ref trả về gì phụ thuộc từng loại tài nguyên — phải tra tài liệu: | Tài nguyên | !Ref trả về | |---|---| | EC2 instance | instance id | | S3 bucket | tên bucket | | RDS DBInstance | DB instance identifier | | IAM role | tên role | | Security group | group id |

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

• B (!Ref) — đây là phương án gần nhất và nó là hàm được dùng nhiều nhất trong CloudFormation. Nhưng với RDS, Ref trả về identifier của instance, không phải endpoint. Đây là nhầm lẫn phổ biến nhất giữa hai hàm, và cách phân biệt là: Ref cho một giá trị đã định sẵn, GetAtt cho bất kỳ thuộc tính nào được tài liệu liệt kê.

• C (!Sub) — hàm thay thế chuỗi: nó chèn giá trị biến vào một chuỗi, ví dụ !Sub "${TenStack}-bucket". Nó không tự lấy được thuộc tính; muốn chèn endpoint thì vẫn phải gọi GetAtt bên trong nó.

• D (!FindInMap) — tra giá trị trong khối Mappings, ví dụ tìm AMI id theo Region. Nó đọc bảng tra cứu tĩnh mà bạn tự khai, không đọc thuộc tính của tài nguyên.

Ghi nhớ

⚠ Các hàm nội tại hay dùng của CloudFormation — bảng phải thuộc: | Hàm | Việc | |---|---| | !Ref | giá trị mặc định của tài nguyên, hoặc giá trị của Parameter | | !GetAtt | một thuộc tính cụ thể của tài nguyên | | !Sub | thay thế biến trong chuỗi | | !FindInMap | tra bảng Mappings | | !Join, !Select, !Split | thao tác chuỗi và danh sách | | !ImportValue | đọc Output đã export từ stack khác | | !If, !Equals, !Not | logic điều kiện |

Từ khoá nhận diện:

"endpoint", "ARN", "DNS name", thuộc tính bất kỳ → !GetAtt "id của tài nguyên" → !Ref chèn giá trị vào chuỗi → !Sub tra AMI theo Region → !FindInMap dùng Output của stack khác → !ImportValue

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên có thuộc tính nào | tra phần Return values trong tài liệu của loại tài nguyên đó | | Output có đúng không | xem tab Outputs của stack sau khi tạo | | Template có hợp lệ không | aws cloudformation validate-template |

Và một lời khuyên: hãy export những Output mà stack khác cần, thay vì chép tay endpoint sang template khác. !ImportValue tạo ra một liên kết thật giữa hai stack: CloudFormation biết stack B đang phụ thuộc vào Output của stack A, nên nó chặn việc xoá hoặc sửa Output đó khi còn ai đang dùng. Chép tay thì không có ràng buộc nào, và ngày ai đó dựng lại stack A với endpoint mới, stack B vẫn trỏ vào địa chỉ cũ mà không có gì cảnh báo.

Đáp án

B — StatusCheckFailed

Vì sao đúng

Đề đòi cảnh báo khi instance hỏng một trong hai loại kiểm tra. Có đúng một chỉ số gộp cả hai.

⚠ Điểm mấu chốt: hai loại status check chỉ ra hai nhóm nguyên nhân khác nhau, và cách xử lý cũng khác:

System status check
        ↓
    Vấn đề ở hạ tầng AWS: mất điện, lỗi mạng, lỗi phần cứng máy chủ vật lý
        ↓
    → cách chữa: STOP rồi START (máy chuyển sang phần cứng khác)

Instance status check
        ↓
    Vấn đề bên trong máy: hệ điều hành treo, hết bộ nhớ, cấu hình mạng sai, đầy đĩa
        ↓
    → cách chữa: khởi động lại, hoặc sửa cấu hình

aws cloudwatch put-metric-alarm --alarm-name kiem-tra-trang-thai \
  --namespace AWS/EC2 --metric-name StatusCheckFailed \
  --dimensions Name=InstanceId,Value=i-0abc123 \
  --statistic Maximum --period 60 --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 2 --alarm-actions <sns-arn>

⚠ Reboot KHÔNG chữa được system status check — phải stop rồi start:

Reboot: máy khởi động lại trên CÙNG phần cứng vật lý
        ↓
    Nếu vấn đề nằm ở phần cứng đó → vẫn hỏng
        ↓
Stop rồi Start: AWS chuyển instance sang phần cứng KHÁC
        ↓
    → đây mới là cách chữa system status check
        ↓
    → lưu ý: dữ liệu trên instance store sẽ MẤT khi stop

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

• A (StatusCheckFailed_Instance) — đây là phương án gần nhất và nó là một chỉ số có thật, rất hữu ích. Nhưng nó chỉ bắt được một nửa yêu cầu: nếu system status check hỏng mà instance check vẫn tốt, alarm không kêu.

• D (StatusCheckFailed_System) — cùng lý do, chỉ bắt nửa còn lại.

• C (CombinedStatusCheckFailed) — không tồn tại chỉ số nào tên như vậy. Tên đúng cho chỉ số gộp là StatusCheckFailed.

Ghi nhớ

⚠ Ba chỉ số status check của EC2 — bảng phải thuộc: | Chỉ số | Bằng 1 khi | |---|---| | StatusCheckFailed_System | hạ tầng AWS có vấn đề | | StatusCheckFailed_Instance | hệ điều hành hoặc cấu hình máy có vấn đề | | StatusCheckFailed | một trong hai cái trên hỏng |

(Từ 2023 có thêm StatusCheckFailed_AttachedEBS cho vấn đề với EBS volume gắn kèm.)

Từ khoá nhận diện:

"either check fails" → StatusCheckFailed "chỉ hạ tầng AWS" → StatusCheckFailed_System "chỉ hệ điều hành" → StatusCheckFailed_Instance CombinedStatusCheckFailed → LUÔN SAI, không tồn tại system check hỏng → stop rồi start, không phải reboot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đang hỏng check nào | tab Status checks trong console EC2 | | Alarm có kêu không | tạm hạ ngưỡng hoặc dùng set-alarm-state để thử | | Auto recovery có bật không | kiểm alarm action của instance |

Và một lời khuyên: hãy đặt EvaluationPeriods ít nhất là 2, đừng để alarm kêu ngay ở lần kiểm tra đầu tiên thất bại. Status check chạy mỗi phút và thỉnh thoảng có một lần trượt thoáng qua mà không phản ánh vấn đề thật — một gói tin mất, một khoảnh khắc máy bận. Nếu alarm kích hoạt ngay lập tức và gắn với hành động reboot hoặc terminate, bạn sẽ có những lần khởi động lại hoàn toàn không cần thiết, và chúng gây gián đoạn thật cho người dùng. Hai chu kỳ liên tiếp là ngưỡng đủ để loại nhiễu mà vẫn phản ứng nhanh.

Đáp án

D — Dùng chỉ số CPUUtilization để xác định năng lực xử lý cần thiết.

Vì sao đúng

Đề hỏi chỉ số giúp xác định năng lực xử lý mà ứng dụng cần. CPUUtilization là chỉ số cơ bản nhất của EC2 và có sẵn không cần cài gì.

⚠ Điểm mấu chốt: CloudWatch có sẵn chỉ số CPU nhưng KHÔNG có sẵn chỉ số bộ nhớ và đĩa:

Chỉ số có sẵn từ hypervisor (không cần agent)
        ↓
    CPUUtilization, NetworkIn/Out, DiskReadOps, StatusCheck...
        ↓
Chỉ số cần CloudWatch agent
        ↓
    Bộ nhớ (mem_used_percent), dung lượng đĩa còn trống (disk_used_percent),
    swap, số tiến trình
        ↓
    → hypervisor không nhìn được vào bên trong hệ điều hành khách

Đây là kiến thức nền quan trọng nhất về giám sát EC2.

⚠ CPUUtilization cao chưa chắc là vấn đề — và thấp chưa chắc là ổn:

CPU 90% liên tục trên máy xử lý theo lô
        ↓
    → đó là dùng hết tài nguyên đã trả tiền, hoàn toàn tốt

CPU 20% mà ứng dụng chậm
        ↓
    → nút thắt nằm ở nơi khác: I/O, mạng, khoá, hoặc chờ cơ sở dữ liệu

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

• B (CPUCreditUsage) — đây là phương án gần nhất và nó là một chỉ số CPU có thật. Nhưng nó chỉ tồn tại với instance dòng T (burstable) và đo lượng credit đã tiêu, không đo mức sử dụng năng lực xử lý. Với instance thường, chỉ số này không có.

• A (CPUProcessPower) — không tồn tại chỉ số nào tên như vậy.

• C (ResourceCount) — không phải chỉ số của EC2; nó xuất hiện trong ngữ cảnh khác (ví dụ đếm tài nguyên trong Config) và không liên quan tới năng lực xử lý.

Ghi nhớ

⚠ Chỉ số EC2 có sẵn so với cần agent — bảng phải thuộc: | Có sẵn (từ hypervisor) | Cần CloudWatch agent | |---|---| | CPUUtilization | bộ nhớ | | NetworkIn, NetworkOut | dung lượng đĩa còn trống | | DiskReadOps, DiskWriteOps (instance store) | swap | | StatusCheckFailed* | số tiến trình | | CPUCreditUsage, CPUCreditBalance (chỉ dòng T) | log ứng dụng |

Từ khoá nhận diện:

"processing power" → CPUUtilization "bộ nhớ" hoặc "dung lượng đĩa" → cần cài CloudWatch agent CPUCreditUsage → chỉ có với instance dòng T | CPUProcessPower → LUÔN SAI, không tồn tại CPU thấp mà chậm → tìm nút thắt ở I/O, mạng, hoặc phụ thuộc bên ngoài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chỉ số bộ nhớ không | tìm namespace CWAgent — không có nghĩa là chưa cài agent | | Chu kỳ là bao lâu | kiểm detailed monitoring đã bật chưa | | CPU có phải nút thắt không | so CPUUtilization với độ trễ ứng dụng |

Và một lời khuyên: hãy cài CloudWatch agent để có chỉ số bộ nhớ trước khi chọn kích cỡ instance. Đây là điểm mù phổ biến nhất trong việc right-size: bạn nhìn CPUUtilization thấy 20% và kết luận máy quá lớn, rồi giảm xuống một lớp nhỏ hơn — và ứng dụng bắt đầu bị OOM killer giết tiến trình, vì thứ nó thiếu là bộ nhớ chứ không phải CPU. Chỉ số đó không tồn tại trong CloudWatch cho tới khi bạn cài agent, nên quyết định của bạn được đưa ra với đúng một nửa bức tranh.

Đáp án

B — Tạo identity-based IAM policy ở tài khoản Finance cho phép người dùng gửi request tới bucket ở HR và Audit; đồng thời tạo resource-based policy ở HR và Audit cho phép người yêu cầu từ Finance truy cập bucket tương ứng.

Vì sao đúng

Đây là truy cập liên tài khoản, và quy tắc đánh giá quyền khác hẳn so với trong cùng một tài khoản.

⚠ Điểm mấu chốt: truy cập liên tài khoản đòi cả hai phía cùng đồng ý — thiếu một bên là bị từ chối:

Người dùng ở Finance gọi s3:GetObject vào bucket của HR
        ↓
    Tài khoản Finance kiểm: identity policy của user có cho phép không?
        ↓
    Tài khoản HR kiểm: bucket policy có cho phép principal đó không?
        ↓
    → chỉ khi CẢ HAI cùng Allow thì request mới thành công

// Ở tài khoản HR — bucket policy
{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::<finance>:user/nguoi-dung"},
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::bao-cao-hr/*"
}

⚠ Object do tài khoản khác ghi vào có thể không thuộc về chủ bucket:

Người dùng Finance chép báo cáo VÀO bucket của Finance → không vấn đề
Nhưng nếu ghi vào bucket của tài khoản khác
        ↓
    Với chế độ ownership cũ, object thuộc về người ghi
        ↓
    → chủ bucket có thể không đọc được chính object trong bucket của mình
    → chế độ "Bucket owner enforced" (mặc định từ 4/2023) đã sửa điều này

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

• A (tạo IAM role ở HR và Audit để người dùng Finance assume khi cần truy cập) — đây là phương án gần nhất và nó là một cách làm hoàn toàn hợp lệ, thậm chí thường được ưa chuộng hơn trong thực tế. Nhưng nó thay đổi quy trình làm việc: người dùng phải chủ động assume role trước mỗi lần truy cập, và khi đó họ mang danh tính của tài khoản kia — nên việc chép ngược về bucket của Finance lại cần thêm một bước hoặc thêm quyền. Với yêu cầu "đọc từ hai nơi rồi ghi về nơi thứ ba", cấp quyền trực tiếp cho chính danh tính của họ đơn giản hơn.

• C (chỉ tạo resource-based policy ở HR và Audit) — thiếu một nửa: identity policy ở tài khoản Finance cũng phải cho phép. Không có nó thì request bị chặn ngay ở phía người gọi.

• D (tạo resource-level permission ở HR và Audit) — mơ hồ về thuật ngữ. "Resource-level permission" thường chỉ việc giới hạn policy tới một ARN cụ thể, không phải một loại policy riêng. Và như C, nó vẫn thiếu vế identity policy.

Ghi nhớ

⚠ Quy tắc đánh giá quyền — bảng phải thuộc: | Trường hợp | Yêu cầu | |---|---| | Cùng tài khoản | một policy cho phép là đủ | | Khác tài khoản | cả identity policy LẪN resource policy | | Deny tường minh ở bất kỳ đâu | thắng tất cả |

Từ khoá nhận diện:

truy cập liên tài khoản → cần cả hai phía cho phép "chỉ resource-based policy" → thiếu identity policy assume role → hợp lệ, nhưng đổi quy trình làm việc object thuộc về ai → kiểm chế độ Object Ownership

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bị chặn ở phía nào | CloudTrail ở tài khoản sở hữu bucket | | Quyền hiệu dụng | aws iam simulate-principal-policy | | Object thuộc về ai | aws s3api get-object-acl |

Và một lời khuyên: hãy đọc CloudTrail ở tài khoản sở hữu bucket, không phải ở tài khoản của người gọi. Với truy cập liên tài khoản, cả hai bên đều ghi lại sự kiện, nhưng chỉ bản ghi ở phía tài nguyên mới thường kèm errorMessage nói rõ chính sách nào đã từ chối. Đội ở tài khoản Finance sẽ nhìn vào log của chính họ, thấy AccessDenied không giải thích gì, và bắt đầu rà soát IAM policy của mình — nơi mọi thứ đều đúng.

Đáp án

D — Status check được xây sẵn trong Amazon EC2 nên không thể tắt cũng không thể xoá.

Vì sao đúng

Đề hỏi cách tắt status check có sẵn để thay bằng script tự viết. Câu trả lời là không có cách nào.

⚠ Điểm mấu chốt: script tự viết BỔ SUNG cho status check, không thay thế nó:

Status check của AWS
        ↓
    Nhìn từ bên ngoài: máy có phản hồi không, hạ tầng có khoẻ không
        ↓
Script giám sát của bạn
        ↓
    Nhìn từ bên trong: ứng dụng có chạy đúng không, hàng đợi có tồn không
        ↓
    → hai góc nhìn khác nhau, giữ cả hai là đúng

Không có lý do gì phải tắt status check: nó miễn phí, không tiêu tài nguyên của máy, và bắt được những sự cố mà script bên trong không thể phát hiện — ví dụ máy treo hoàn toàn.

⚠ Điều bạn tắt được là ALARM, không phải bản thân status check:

Không tắt được: bản thân việc kiểm tra
Tắt được: CloudWatch alarm bạn tạo dựa trên chỉ số StatusCheckFailed
        ↓
    → nếu script của bạn đã bao phủ, chỉ cần không tạo alarm trùng lặp

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

• C (status check được xây sẵn nên không tắt được, nhưng có thể xoá khỏi cấu hình đang chạy) — đây là phương án gần nhất và nửa đầu của nó chính xác. Nhưng "xoá khỏi cấu hình đang chạy" là một thao tác không tồn tại: không có nơi nào liệt kê status check như một mục cấu hình để gỡ bỏ.

• A (kiểm tra phần cứng không tắt được, nhưng kiểm tra phần mềm thì tắt được) — không có sự phân biệt nào như vậy. Cả system check lẫn instance check đều không tắt được.

• B (status check gắn với CloudWatch metric, có thể tắt từ console CloudWatch metric) — nhầm hai thứ. CloudWatch nhận và hiển thị chỉ số status check, nhưng nó không điều khiển việc kiểm tra. Và console CloudWatch không có nút tắt chỉ số.

Ghi nhớ

⚠ Hai loại status check của EC2 — bảng phải thuộc: | Loại | Kiểm gì | Cách chữa | |---|---|---| | System status check | hạ tầng AWS: điện, mạng, phần cứng | stop rồi start | | Instance status check | hệ điều hành, cấu hình mạng, đầy đĩa | reboot hoặc sửa cấu hình |

Từ khoá nhận diện:

"tắt status check" → không thể, nó là một phần của EC2 "xoá status check khỏi cấu hình" → không tồn tại thao tác đó system check hỏng → stop/start, KHÔNG phải reboot instance check hỏng → vấn đề bên trong máy | script riêng → bổ sung, không thay thế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đang hỏng check nào | tab Status checks trong console EC2 | | Có alarm nào không | describe-alarms lọc theo instance | | Script riêng có chạy không | kiểm chỉ số tuỳ chỉnh trong CloudWatch |

Và một lời khuyên: hãy giữ status check của AWS và thêm giám sát của riêng bạn bên cạnh, đừng coi chúng là hai lựa chọn loại trừ nhau. Script bên trong máy chỉ báo cáo được khi máy còn chạy — nghĩa là đúng vào lúc sự cố nghiêm trọng nhất, khi hệ điều hành treo hoặc phần cứng hỏng, nó im lặng hoàn toàn. Status check nhìn từ bên ngoài nên nó vẫn phát hiện được, và đó chính là loại sự cố bạn cần biết nhất.

Đáp án

B — Lỗi này cho biết bucket S3 đã được chuyển từ Region này sang Region khác (xoá ở một nơi rồi tạo lại cùng tên ở nơi khác). Cần cập nhật CloudFront distribution để nó tìm bucket ở Region hiện tại.

Vì sao đúng

Thông báo lỗi nói chính xác vấn đề: "the region '' is wrong; expecting ''" — CloudFront đang ký request cho một Region, còn bucket lại ở Region khác.

⚠ Điểm mấu chốt: chữ ký SigV4 bao gồm Region — nên CloudFront phải biết đúng Region của bucket:

CloudFront ký request tới origin bằng SigV4
        ↓
    Chữ ký chứa Region mà nó tin là bucket đang ở đó
        ↓
    Bucket đã chuyển sang Region khác (xoá rồi tạo lại cùng tên)
        ↓
    → S3 từ chối: "the region is wrong; expecting..."
        ↓
    → cập nhật origin trong CloudFront để trỏ đúng Region

⚠ Tên bucket là toàn cầu nhưng dữ liệu thì theo Region — đó là chỗ gây nhầm lẫn:

Tên bucket duy nhất trên toàn thế giới
        ↓
    Nhưng bucket sống ở một Region cụ thể
        ↓
    Xoá bucket rồi tạo lại cùng tên ở Region khác là hoàn toàn hợp lệ
        ↓
    → mọi thứ trỏ tới nó bằng tên vẫn "tìm thấy", nhưng ký sai Region

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

• D (lỗi này nghĩa là CloudFront và S3 không cùng Region, hãy chuyển một trong hai về cùng Region) — đây là phương án gần nhất và nó nhắc đúng tới sự lệch Region. Nhưng nó hiểu sai kiến trúc: CloudFront là dịch vụ toàn cầu, nó không nằm ở Region nào cả, nên khái niệm "cùng Region với S3" không tồn tại. Bucket ở bất kỳ Region nào cũng làm origin được — vấn đề chỉ là CloudFront phải biết đúng Region đó.

• A (origin không phản hồi trước khi request hết hạn, có thể do firewall hoặc security group chặn) — đó là mô tả của lỗi 504 Gateway Timeout, không phải lỗi về authorization header. Và S3 không đứng sau security group.

• C (API key dùng để uỷ quyền đến từ Region khác với Region của bucket) — không có "API key" trong luồng CloudFront tới S3; xác thực dùng OAC/OAI với chữ ký SigV4.

Ghi nhớ

⚠ Bốn lỗi thường gặp giữa CloudFront và S3 — bảng phải thuộc: | Lỗi | Nguyên nhân | |---|---| | region is wrong; expecting | origin trỏ sai Region của bucket | | 403 Access Denied | thiếu OAC/OAI trong bucket policy, hoặc Block Public Access | | 504 Gateway Timeout | origin không phản hồi kịp | | 404 Not Found | object không tồn tại, hoặc sai path pattern |

Từ khoá nhận diện:

"the region is wrong" → origin trỏ sai Region, cập nhật distribution "CloudFront phải cùng Region với S3" → SAI, CloudFront là toàn cầu "API key" trong luồng CloudFront–S3 → không tồn tại timeout → 504, khác hẳn lỗi authorization

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket đang ở Region nào | aws s3api get-bucket-location --bucket <ten> | | Origin của CloudFront trỏ đâu | get-distribution-config, xem DomainName của origin | | Có lỗi origin nào không | log của CloudFront, hoặc chỉ số 5xxErrorRate |

Và một lời khuyên: hãy dùng tên miền đầy đủ có chứa Region cho origin S3, thay vì dạng rút gọn. Endpoint dạng bucket.s3.ap-southeast-1.amazonaws.com nêu rõ Region trong chính tên, nên khi ai đó nhìn vào cấu hình distribution, họ thấy ngay bucket được kỳ vọng ở đâu. Dạng rút gọn bucket.s3.amazonaws.com dựa vào việc chuyển hướng của S3 và che mất thông tin đó — nên khi bucket đổi Region, cấu hình vẫn trông y hệt như cũ trong khi đã sai, và không ai đọc nó mà nhận ra điều gì bất thường.

Đáp án

C — Để tự động thay thế EC2 instance không khoẻ, phải đổi health check type của Auto Scaling group từ EC2 sang ELB, và làm việc đó bằng CONFIGURATION FILE của môi trường Beanstalk.

Vì sao đúng

Đề có hai phần, và phần thứ hai là điểm phân biệt: đổi health check type, và đổi ở đâu.

⚠ Điểm mấu chốt: sửa trực tiếp tài nguyên do Beanstalk quản lý sẽ bị ghi đè:

Sửa ASG từ console EC2
        ↓
    Beanstalk không biết về thay đổi đó
        ↓
    Lần cập nhật môi trường tiếp theo, Beanstalk dựng lại theo cấu hình của nó
        ↓
    → thay đổi của bạn biến mất, không có cảnh báo nào
        ↓
Sửa bằng .ebextensions
        ↓
    Thay đổi trở thành một phần cấu hình môi trường, tồn tại qua mọi lần cập nhật

# .ebextensions/autoscaling.config
Resources:
  AWSEBAutoScalingGroup:
    Type: "AWS::AutoScaling::AutoScalingGroup"
    Properties:
      HealthCheckType: ELB
      HealthCheckGracePeriod: 300

⚠ EC2 health check chỉ thấy máy còn sống — ELB health check thấy ứng dụng còn phục vụ:

EC2 health check
        ↓
    Máy đang chạy, status check qua → coi là khoẻ
    Kể cả khi ứng dụng đã treo
        ↓
ELB health check
        ↓
    Gọi một endpoint của ứng dụng, đọc mã phản hồi
        ↓
    → ứng dụng treo → target unhealthy → ASG thay máy

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

• B (sửa ASG trực tiếp từ console EC2 để đổi health check type sang ELB) — đây là phương án gần nhất và nó chọn đúng health check type. Nhưng nó sửa sai chỗ: tài nguyên do Beanstalk tạo và quản lý, nên thay đổi thủ công sẽ bị ghi đè ở lần cập nhật môi trường tiếp theo. Đây là bẫy kiểm tra hiểu biết về cách Beanstalk quản lý tài nguyên.

• A (sửa trực tiếp từ console EC2 để đổi sang EC2) — sai cả hai vế: sai chỗ sửa, và EC2 là giá trị mặc định đang gây ra vấn đề.

• D (dùng configuration file để đổi từ ELB sang EC2) — đúng chỗ sửa nhưng đảo ngược chiều: đổi sang EC2 làm health check kém nhạy hơn, đúng thứ đề muốn tránh.

Ghi nhớ

⚠ Hai loại health check của Auto Scaling group — bảng phải thuộc: | Loại | Kiểm gì | |---|---| | EC2 (mặc định) | status check của instance — máy còn sống | | ELB | health check của load balancer — ứng dụng còn phục vụ |

Từ khoá nhận diện:

"thay thế instance không khoẻ theo góc nhìn ứng dụng" → health check type ELB môi trường Beanstalk → sửa bằng .ebextensions, không sửa trực tiếp sửa tài nguyên do Beanstalk quản lý bằng tay → sẽ bị ghi đè đổi sang EC2 → kém nhạy hơn, ngược yêu cầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Health check type hiện tại | describe-auto-scaling-groups, xem HealthCheckType | | Cấu hình có bền không | cập nhật môi trường rồi kiểm lại | | Endpoint health check có đủ sâu không | nó phải chạm tới phụ thuộc quan trọng |

Và một lời khuyên: hãy đặt HealthCheckGracePeriod dài hơn thời gian khởi động thật của ứng dụng trước khi chuyển sang ELB health check. Đây là chỗ một cải thiện đúng đắn gây ra sự cố tệ hơn: ELB health check nhạy hơn nhiều, nên nếu ứng dụng của bạn mất ba phút để sẵn sàng mà grace period chỉ có sáu mươi giây, mọi instance mới đều bị đánh dấu hỏng trước khi kịp phục vụ — và ASG rơi vào vòng lặp dựng máy rồi huỷ máy liên tục. Nó trông giống hệt một sự cố hạ tầng, nhưng nguyên nhân là một tham số thời gian.

Đáp án

A — AWS MFA không hỗ trợ dùng lại thiết bị Gemalto sẵn có của bạn.

Vì sao đúng

Thiết bị MFA phần cứng hoạt động dựa trên một bí mật dùng chung được nạp vào thiết bị lúc sản xuất. Bí mật đó chỉ được chia sẻ với một bên.

⚠ Điểm mấu chốt: bí mật trong thiết bị phần cứng là cố định và chỉ đăng ký được với một bên:

Thiết bị Gemalto đã đăng ký với hệ thống của công ty cũ
        ↓
    Seed của nó nằm trong hệ thống đó
        ↓
    AWS không có seed ấy và không có cách nào lấy được
        ↓
    → không xác minh được mã OTP mà thiết bị sinh ra
        ↓
    → phải mua thiết bị mới đã đăng ký với AWS, hoặc dùng lựa chọn khác

⚠ Có nhiều lựa chọn MFA khác không cần mua thiết bị: | Loại | Chi phí | |---|---| | Virtual MFA (Google Authenticator, Authy) | miễn phí — điện thoại là đủ | | Passkey / FIDO2 | thiết bị hoặc sinh trắc học có sẵn trên máy | | Hardware TOTP token | phải mua từ nhà cung cấp AWS hỗ trợ | | U2F security key | YubiKey và tương đương |

Với một quản lý mới cần MFA ngay, virtual MFA là lựa chọn nhanh nhất và không tốn gì.

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

• C (AWS MFA dựa trên một bí mật duy nhất gắn với thiết bị phần cứng; phải sinh lại bí mật đó với AWS để thiết bị Gemalto hoạt động) — đây là phương án gần nhất và nửa đầu của nó mô tả đúng cơ chế: MFA phần cứng thật sự dựa trên một bí mật gắn với thiết bị. Nhưng kết luận sai: bí mật đó không sinh lại được trên một thiết bị đã xuất xưởng. Đó chính là lý do khiến thiết bị an toàn — nếu ai cũng nạp lại được seed thì cơ chế mất hết ý nghĩa.

• D (dùng lại được vì thiết bị Gemalto không chia sẻ bí mật giữa nhiều bên) — hiểu ngược: chính vì không chia sẻ với nhiều bên nên nó chỉ dùng được với một bên, và bên đó là công ty cũ.

• B (cần phê duyệt chính thức giữa AWS và công ty cũ để dùng chung thiết bị) — không có quy trình nào như vậy; đây không phải vấn đề thủ tục mà là giới hạn kỹ thuật.

Ghi nhớ

⚠ Bốn loại MFA mà AWS hỗ trợ — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | Virtual MFA | ứng dụng trên điện thoại, miễn phí | | Passkey / FIDO2 | vân tay, khuôn mặt, hoặc security key | | Hardware TOTP token | thiết bị vật lý sinh mã 6 số | | U2F security key | cắm USB hoặc NFC |

Từ khoá nhận diện:

"dùng lại thiết bị MFA từ nơi khác" → không được "sinh lại bí mật cho thiết bị cũ" → SAI, seed cố định từ nhà máy cần MFA nhanh và rẻ → virtual MFA yêu cầu bảo mật cao nhất → FIDO2 security key |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai chưa bật MFA | báo cáo IAM credential report | | MFA có bắt buộc thật không | thử một hành động với phiên chưa MFA | | Root có MFA chưa | kiểm trang Security credentials của root |

Và một lời khuyên: hãy cho phép mỗi người đăng ký nhiều hơn một thiết bị MFA. AWS hỗ trợ tới tám thiết bị cho một danh tính, và điều đó giải quyết trọn vẹn kịch bản tệ nhất của MFA: người dùng mất điện thoại, hoặc đổi máy mà quên chuyển ứng dụng xác thực. Không có thiết bị dự phòng, quy trình khôi phục đòi liên hệ AWS Support và xác minh danh tính — mất hàng giờ tới hàng ngày. Với một thiết bị thứ hai đã đăng ký sẵn, đó chỉ là chuyện mở ứng dụng trên máy khác.

Đáp án

A — Bật Sticky Sessions trên Application Load Balancer.

Vì sao đúng

Triệu chứng của đề rất đặc trưng: người dùng bị đăng xuất nhiều lần trong một giờ, và chỉ xảy ra ở production.

⚠ Điểm mấu chốt: phiên lưu trên từng máy + load balancer phân phối đều = mất phiên liên tục:

Người dùng đăng nhập → phiên được lưu trên máy A
        ↓
    Request tiếp theo → ALB gửi tới máy B
        ↓
    Máy B không có phiên đó → yêu cầu đăng nhập lại
        ↓
    → xảy ra liên tục, và KHÔNG xuất hiện ở môi trường một máy

Sticky session buộc ALB gửi cùng một người dùng về đúng máy đã phục vụ họ:

aws elbv2 modify-target-group-attributes --target-group-arn <arn> \
  --attributes Key=stickiness.enabled,Value=true \
               Key=stickiness.type,Value=lb_cookie \
               Key=stickiness.lb_cookie.duration_seconds,Value=86400

⚠ Sticky session là cách chữa nhanh, không phải cách chữa gốc:

Sticky session giữ người dùng ở một máy
        ↓
    Máy đó chết → phiên vẫn mất
    Tải phân bổ lệch vì phiên dài bám vào vài máy
        ↓
    → cách bền là đưa phiên ra ngoài: ElastiCache Redis hoặc DynamoDB
    → khi đó mọi máy tương đương, sticky session không còn cần thiết

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

• C (dùng Slow Start Mode khi đăng ký target để instance có thời gian khởi động và không mất dữ liệu cache) — đây là phương án gần nhất và Slow Start là tính năng có thật của ALB. Nhưng vai trò của nó khác: nó tăng dần lưu lượng vào một target mới đăng ký để ứng dụng kịp làm nóng cache và kết nối. Nó không liên quan gì tới việc phiên của người dùng nằm ở máy nào, và không giải quyết triệu chứng đăng xuất.

• B (dùng cấu hình routing của load balancer để đặt đúng giao thức và cổng) — sai giao thức hay cổng thì ứng dụng hoàn toàn không truy cập được, chứ không phải hoạt động rồi thỉnh thoảng đăng xuất.

• D (bật logging trên ALB và xem log để tìm lỗi) — là bước chẩn đoán hợp lý nói chung, nhưng đề đã mô tả rõ triệu chứng và hỏi cách sửa. Log của ALB cũng không ghi lại việc ứng dụng xử lý phiên thế nào.

Ghi nhớ

⚠ Bốn nơi lưu phiên — bảng phải thuộc: | Nơi | Sống sót khi mất máy | Cần sửa mã | |---|---|---| | Sticky session ở ALB | không | không | | ElastiCache Redis | có | có | | DynamoDB | có | có | | Cookie phía client | có | có, và giới hạn dung lượng |

Từ khoá nhận diện:

"đăng xuất nhiều lần, chỉ ở production" → phiên lưu cục bộ + nhiều máy cách nhanh nhất, không sửa mã → sticky session cách bền vững → đưa phiên ra ngoài máy chủ "Slow Start Mode" → làm nóng target mới, không liên quan phiên sai giao thức hoặc cổng → không truy cập được, không phải đăng xuất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sticky session có hoạt động không | gửi nhiều request cùng cookie, xem có về một target không | | Tải có lệch không | chỉ số RequestCount theo từng target | | Mất máy có mất phiên không | huỷ thử một instance và quan sát |

Và một lời khuyên: hãy coi sticky session là biện pháp tạm và lên kế hoạch đưa phiên ra kho ngoài. Nó chữa được triệu chứng ngay hôm nay mà không cần chạm vào mã, và đó là giá trị thật của nó. Nhưng nó không làm ứng dụng của bạn thành stateless: mỗi lần một instance bị thay — do co giãn, do triển khai, do health check thất bại — những người dùng đang bám vào máy đó vẫn mất phiên. Sự cố nhỏ đi rất nhiều nhưng không biến mất, và nó sẽ quay lại đúng vào những ngày bạn triển khai phiên bản mới.

Đáp án

B — Bạn phải tự tạo một hoặc nhiều DB instance mới ở Availability Zone khác.

Vì sao đúng

Đề nêu một tình huống rất cụ thể: primary và TẤT CẢ reader đều nằm trong cùng một AZ, và AZ đó gặp sự cố.

⚠ Điểm mấu chốt: lưu trữ Aurora luôn trải ba AZ, nhưng KHẢ NĂNG PHỤC VỤ phụ thuộc vào vị trí các instance:

Aurora sao chép lưu trữ sáu bản trên ba AZ — luôn luôn, không cần cấu hình
        ↓
    Dữ liệu của bạn an toàn dù mất một AZ
        ↓
    NHƯNG nếu mọi instance đều ở AZ vừa mất
        ↓
    → không có instance nào để thăng cấp
    → phải tạo instance MỚI ở AZ khác, nó sẽ gắn vào lớp lưu trữ còn nguyên vẹn

Đây là lý do vì sao "Aurora tự chuyển dự phòng" chỉ đúng khi bạn đã đặt replica ở AZ khác.

⚠ Cách phòng ngừa: luôn đặt reader ở AZ khác với writer:

aws rds create-db-instance --db-instance-identifier reader-1b \
  --db-cluster-identifier cum-chinh --availability-zone ap-southeast-1b \
  --db-instance-class db.r6g.large --engine aurora-mysql

Aurora chọn replica có failover priority (tier) thấp nhất để thăng cấp; cùng tier thì chọn instance lớn nhất.

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

• A (Aurora thăng cấp một replica ở AZ khác, nên không cần làm gì) — đây là phương án gần nhất và nó mô tả đúng hành vi bình thường của Aurora. Nhưng nó bỏ qua chính điều kiện của đề: không có replica nào ở AZ khác — tất cả đều ở AZ vừa mất. Đây là bẫy chọn hành vi mặc định mà quên dữ kiện đặc biệt.

• C (Aurora tự tạo primary mới trong cùng AZ) — AZ đó đang mất, nên không tạo được gì ở đó. Aurora cũng không tự tạo instance mới để thay thế theo cách này.

• D (với cụm single-master, Aurora tạo được tới 15 Aurora Replica để phục vụ request) — là một sự thật đúng về Aurora nhưng không trả lời câu hỏi: đề hỏi hành động cần làm để đưa cơ sở dữ liệu trở lại, không hỏi giới hạn số replica.

Ghi nhớ

⚠ Bốn điều về tính sẵn sàng của Aurora — bảng phải thuộc: | Điều | Nội dung | |---|---| | Lưu trữ | luôn 6 bản trên 3 AZ — mặc định | | Instance | chỉ ở AZ bạn khai — đây là chỗ quyết định | | Thăng cấp tự động | chỉ khi có replica ở AZ còn sống | | Thời gian chuyển dự phòng | thường dưới 30 giây |

Từ khoá nhận diện:

"mọi instance cùng một AZ" → không có gì để thăng cấp "Aurora tự thăng cấp" → chỉ đúng khi có replica ở AZ khác lưu trữ vẫn an toàn → đúng, nhưng cần instance mới để phục vụ phòng ngừa → luôn đặt reader ở AZ khác writer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance nằm ở AZ nào | describe-db-instances, xem AvailabilityZone của từng cái | | Chuyển dự phòng có chạy không | aws rds failover-db-cluster trong giờ thấp điểm | | Ứng dụng dùng endpoint nào | kiểm chuỗi kết nối là cluster endpoint |

Và một lời khuyên: hãy kiểm tra AZ của từng instance trong cụm, đừng tin vào việc Aurora "vốn đã sẵn sàng cao". Lưu trữ trải ba AZ là mặc định và không tắt được, nên bảng điều khiển luôn tạo cảm giác cụm đã được bảo vệ — và trong phần lớn thời gian điều đó đúng, vì dữ liệu thật sự an toàn. Nhưng khả năng tiếp tục phục vụ phụ thuộc hoàn toàn vào việc bạn có instance ở nơi khác hay không, và đó là một quyết định bạn đưa ra lúc tạo từng instance chứ không phải một thuộc tính của cụm.