Kiểm tra nhanh

1. Vault CLI thực chất là gì ở bên dưới?

• Một binary độc lập, không liên quan đến HTTP API
• Một wrapper mỏng gọi HTTP API của Vault
• Một gRPC client kết nối trực tiếp đến Vault core
• Một WebSocket client để nhận push notification từ Vault

2. Header HTTP nào được dùng để truyền Vault token trong API request?

• Authorization: Bearer <token>
• X-Auth-Token: <token>
• X-Vault-Token: <token>
• Vault-Token: <token>

3. Trong workflow 5 bước của Vault, điều gì xảy ra ngay sau khi Vault xác thực credentials thành công?

• Vault trả dữ liệu được yêu cầu ngay lập tức
• Vault cấp token kèm TTL và danh sách policies
• Client phải gửi request riêng để lấy token
• Vault ghi audit log rồi mới cấp token

4. Điểm khác biệt chính giữa service token (bắt đầu bằng hvs.) và batch token (bắt đầu bằng hvb.) là gì?

• Service token renewable và tạo được child token, batch token thì không
• Batch token bảo mật hơn vì dùng thuật toán mã hóa mạnh hơn
• Service token dùng cho machine còn batch token dùng cho human operators
• Batch token có TTL dài hơn service token mặc định

5. Lệnh xem chi tiết token hiện tại (TTL, policies, accessor): `vault token _______`

6. Capability nào trong Vault luôn override mọi capability khác, kể cả khi policy khác cho phép?

• sudo
• deny
• root
• revoke

7. Điều gì cần lưu ý về capability `list` từ góc độ bảo mật?

• list không filter theo policy — tên của keys có thể bị lộ dù token không có read
• list yêu cầu capability sudo mới thực hiện được
• list chỉ hiển thị metadata, không bao giờ lộ tên keys
• list tương đương với read — có read thì tự động có list

8. Khi một Vault token hết TTL và bị revoke, điều gì xảy ra với dynamic secrets được cấp trong phiên đó?

• Toàn bộ lease và dynamic secrets liên quan cũng bị thu hồi tự động
• Dynamic secrets tiếp tục sống đến khi hết TTL riêng của chúng
• Dynamic secrets phải được revoke thủ công bởi admin
• Chỉ secrets engine loại database bị ảnh hưởng, các loại khác không