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

Đáp án

C — Dùng Lifecycle Policy của Elastic Beanstalk.

Vì sao đúng

Elastic Beanstalk có giới hạn 1.000 application version mỗi ứng dụng (mặc định). Với CI/CD chạy liên tục hơn một năm, chạm trần là chuyện tất yếu — và khi đó không tạo được version mới nữa, pipeline dừng.

Application version lifecycle policy tự dọn version cũ, và khai bằng cấu hình:

aws elasticbeanstalk update-application \
  --application-name ung-dung \
  --resource-lifecycle-config '{
    "ServiceRole": "arn:aws:iam::123456789012:role/aws-elasticbeanstalk-service-role",
    "VersionLifecycleConfig": {
      "MaxCountRule": {
        "Enabled": true,
        "MaxCount": 100,
        "DeleteSourceFromS3": true
      }
    }
  }'

Hai kiểu luật, chọn một: | Luật | Giữ lại | |---|---| | MaxCountRule | N version gần nhất | | MaxAgeRule | version trẻ hơn N ngày |

Tuỳ chọn đáng chú ý: DeleteSourceFromS3 — xoá luôn gói mã nguồn trên S3, không chỉ bản ghi version. Không bật thì bucket phình ra mãi.

Và cơ chế bảo vệ quan trọng: Beanstalk KHÔNG BAO GIỜ xoá version đang được một môi trường sử dụng, kể cả khi nó vượt quá số lượng hoặc quá hạn.

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

• B. Viết một Lambda function — làm được (gọi delete-application-version theo lịch), nhưng đây là tự viết lại một tính năng đã có sẵn: phải tự lên lịch, tự xác định version nào đang dùng, tự xử lý lỗi. Lifecycle policy làm cùng việc bằng một cấu hình.
• A. Dùng .ebextensions — dùng để cấu hình môi trường (cài gói, tạo tệp, chạy lệnh lúc deploy). Nó không quản lý vòng đời application version, vốn là khái niệm ở mức application, không phải mức môi trường.
• D. Dùng worker environment — đổi kiểu môi trường (nhận việc từ SQS thay vì HTTP). Hoàn toàn không liên quan tới việc dọn version.

Ghi nhớ

Các giới hạn của Elastic Beanstalk đáng biết: | Giới hạn | Giá trị mặc định | |---|---| | Application version mỗi ứng dụng | 1.000 | | Ứng dụng mỗi Region | 75 | | Môi trường mỗi Region | 200 | | Cấu hình template mỗi ứng dụng | 300 |

Khuyến nghị: bật lifecycle policy ngay từ đầu cho mọi ứng dụng có CI/CD. Nó là lưới an toàn miễn phí chống đúng sự cố trong đề — pipeline dừng đột ngột vì chạm một giới hạn mà không ai để ý.

Đáp án

B — Tạo một customer-managed policy dùng policy variable và gắn vào một group chứa tất cả người dùng.

Vì sao đúng

Với 200 người dùng và mỗi người cần một thư mục riêng, viết policy cho từng người là không thể bảo trì. Policy variable giải quyết bằng cách chèn giá trị động tại thời điểm đánh giá:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my_company_space",
      "Condition": {"StringLike": {"s3:prefix": ["home/${aws:username}/*"]}}
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::my_company_space/home/${aws:username}/*"
    }
  ]
}

${aws:username} được thay bằng tên của người gọi tại mỗi lần đánh giá. Nên một policy duy nhất phục vụ cả 200 người, mỗi người bị khoá vào đúng thư mục của mình:

my_company_space/home/nguyen-van-a/    ← chỉ nguyen-van-a truy cập được
my_company_space/home/tran-thi-b/      ← chỉ tran-thi-b

Gắn vào group thì thêm người dùng mới chỉ là thêm họ vào group — không viết gì thêm.

Statement ListBucket với điều kiện s3:prefix là phần cần thiết để người dùng liệt kê được thư mục của mình mà không thấy thư mục người khác.

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

• C. Một customer-managed policy cho mỗi người dùng — 200 policy phải bảo trì, và mỗi lần đổi quy tắc là sửa 200 chỗ. Ngoài ra IAM có giới hạn số policy quản lý được gắn cho mỗi identity và quota policy trong tài khoản.
• A. Inline policy cho từng người khi onboard — tệ hơn nữa: inline policy không tái sử dụng được, không xem tập trung được, và bị xoá cùng người dùng. Quản lý 200 inline policy là ác mộng vận hành.
• D. Bucket policy sửa mỗi khi thêm/bớt người dùng — bucket policy có giới hạn kích thước 20 KB, và 200 người dùng sẽ vượt rất nhanh. Nó cũng đòi sửa một tài nguyên dùng chung ở mỗi lần thay đổi nhân sự — dễ gây sự cố diện rộng.

Ghi nhớ

Các policy variable hay dùng: | Biến | Giá trị | |---|---| | ${aws:username} | tên IAM user (chỉ có với IAM user, không có với role) | | ${aws:userid} | ID duy nhất của principal | | ${aws:PrincipalTag/<key>} | tag của principal — nền tảng của ABAC | | ${cognito-identity.amazonaws.com:sub} | identity ID của Cognito |

Với IAM role (không có ${aws:username}), dùng ABAC với ${aws:PrincipalTag/...} — cùng nguyên lý, một policy cho mọi người, quyền quyết định bởi tag.

Đáp án

B — AWS_XRAY_DAEMON_ADDRESS.

Vì sao đúng

X-Ray SDK cần biết daemon đang ở đâu để gửi segment qua UDP. Mặc định nó giả định 127.0.0.1:2000, nhưng trong môi trường container thì địa chỉ có thể khác — nên có biến môi trường này để khai tường minh:

"environment": [
  {"name": "AWS_XRAY_DAEMON_ADDRESS", "value": "xray-daemon:2000"}
]

Giá trị phụ thuộc vào network mode của ECS task — đây là chi tiết thực tế quan trọng:

Với bridge mode, task definition cần thêm:

"links": ["xray-daemon"]

Vì sao các phương án khác sai (tức là chúng đều là biến thật, nhưng khác mục đích)

• A. AWS_XRAY_DEBUG_MODE — bật ghi log gỡ lỗi của chính SDK. Hữu ích khi chẩn đoán vì sao trace không tới, nhưng nó không định vị daemon.
• C. AWS_XRAY_TRACING_NAME — đặt tên service hiển thị trong service map của X-Ray. Ảnh hưởng tới cách trace được gán nhãn, không tới việc kết nối daemon.
• D. AWS_XRAY_CONTEXT_MISSING — quyết định SDK làm gì khi không tìm thấy segment context (ví dụ mã chạy ngoài một request). Giá trị: RUNTIME_ERROR (ném lỗi), LOG_ERROR (chỉ ghi log), IGNORE_ERROR. Rất hữu ích để tránh làm sập ứng dụng, nhưng không liên quan tới địa chỉ daemon.

Ghi nhớ

Bốn biến môi trường của X-Ray SDK: | Biến | Vai trò | |---|---| | AWS_XRAY_DAEMON_ADDRESS | địa chỉ daemon | | AWS_XRAY_TRACING_NAME | tên service trong service map | | AWS_XRAY_CONTEXT_MISSING | hành vi khi thiếu context (nên đặt LOG_ERROR trong production) | | AWS_XRAY_DEBUG_MODE | bật log gỡ lỗi của SDK |

Danh sách kiểm khi X-Ray không có dữ liệu trên ECS:

1. Daemon container đã chạy chưa? (sidecar)
2. AWS_XRAY_DAEMON_ADDRESS đúng với network mode chưa?
3. Task role có xray:PutTraceSegments chưa?
4. UDP cổng 2000 có thông giữa hai container không?

Đáp án

B — Annotations.

Vì sao đúng

X-Ray cho phép gắn dữ liệu tuỳ ý vào segment, và có hai loại với khác biệt rất quan trọng:

Đề nói rõ cần "index your traces to search and filter through them efficiently" ⇒ annotations.

from aws_xray_sdk.core import xray_recorder

# Annotation — ĐƯỢC lập chỉ mục, lọc được
xray_recorder.put_annotation('user_id', 'u-12345')
xray_recorder.put_annotation('loai_don', 'premium')
xray_recorder.put_annotation('gia_tri', 1500)

# Metadata — KHÔNG lập chỉ mục, chỉ để đọc khi mở trace ra
xray_recorder.put_metadata('chi_tiet_don', {'san_pham': [...], 'ghi_chu': '...'})

Rồi lọc bằng filter expression trong console hoặc API:

annotation.user_id = "u-12345"
annotation.loai_don = "premium" AND annotation.gia_tri > 1000

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

• A. Metadata — bẫy chính, và khác biệt duy nhất nhưng quyết định: metadata KHÔNG được lập chỉ mục, nên không lọc được. Nó chỉ hiển thị khi bạn mở một trace cụ thể ra xem. Dùng cho dữ liệu phong phú không cần tìm kiếm.
• C. Segments — đơn vị dữ liệu cơ bản của X-Ray: mỗi segment mô tả công việc của một dịch vụ trong một request. Segment là cái chứa annotation và metadata, không phải cơ chế lập chỉ mục.
• D. Sampling — quyết định bao nhiêu phần trăm request được ghi lại, dùng để kiểm soát chi phí. Nó ảnh hưởng tới số lượng trace, không tới khả năng tìm kiếm.

Ghi nhớ

Cấu trúc dữ liệu của X-Ray:

Trace (một request đầu-cuối)
└── Segment (công việc của một dịch vụ)
    ├── Subsegment (một lời gọi downstream: DynamoDB, HTTP…)
    ├── Annotations  ← ĐƯỢC LẬP CHỈ MỤC, lọc được, tối đa 50
    └── Metadata     ← không lập chỉ mục, tự do

Quy tắc chọn: cái gì bạn sẽ dùng để TÌM trace thì đặt vào annotation; cái gì chỉ để ĐỌC khi đã tìm ra thì đặt vào metadata.

Ví dụ điển hình: user_id, order_id, tenant_id, environment ⇒ annotation. Toàn bộ payload request, danh sách sản phẩm, stack trace chi tiết ⇒ metadata.

Đáp án

A — MessageGroupId.

Vì sao đúng

FIFO queue có hai tham số riêng biệt, và câu này hỏi cái đầu tiên:

Đề cần thứ tự theo từng user_id ⇒ đặt user_id làm MessageGroupId:

sqs.send_message(
    QueueUrl=url,
    MessageBody=json.dumps(hanh_dong),
    MessageGroupId=user_id,                    # ← thứ tự trong phạm vi người dùng này
    MessageDeduplicationId=hanh_dong['id']
)

Cách nó hoạt động — và đây là điểm hay của thiết kế:

Nên với user_id làm group ID: hành động của cùng một người giữ đúng thứ tự, còn hành động của những người khác nhau được xử lý song song. Bạn có cả thứ tự lẫn thông lượng.

Đây cũng là mẹo tăng thông lượng cho FIFO queue: chọn MessageGroupId có độ phân tán cao. Dùng một giá trị cố định cho mọi message sẽ tuần tự hoá toàn bộ hàng đợi.

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

• D. MessageDeduplicationId — bẫy sát nhất vì nó cũng là tham số bắt buộc của FIFO. Nhưng nó chống trùng lặp, không đảm bảo thứ tự. Đặt user_id vào đây sẽ gây hậu quả nghiêm trọng: mọi message của cùng một người dùng trong 5 phút sẽ bị coi là trùng và bị loại bỏ.
• B. "MessageHash" và C. "MessageOrderId" — cả hai đều không tồn tại. Đây là tên bịa nghe hợp lý.

Ghi nhớ

Và nhớ đặc điểm thông lượng của FIFO: 300 message/giây (3.000 với batching), cao hơn nhiều với high throughput mode — nhưng chỉ khi message trải đều trên nhiều message group.

Đáp án

B — Security Groups.

Vì sao đúng

Triệu chứng: khách truy cập từ Internet nhận timeout, không phải lỗi HTTP.

Đây là dấu hiệu phân biệt rất rõ: timeout nghĩa là gói tin không tới được đích — không có ai trả lời. Nếu ứng dụng chết hoặc lỗi thì bạn sẽ nhận 502, 503 hoặc 504 từ load balancer, không phải timeout thuần.

Với kiến trúc Internet-facing ALB + EC2, có hai security group phải cấu hình đúng:

Vế thứ hai là chỗ hay sai nhất: instance phải cho phép security group của ALB, không phải một dải IP:

aws ec2 authorize-security-group-ingress --group-id sg-instance \
  --protocol tcp --port 80 --source-group sg-alb

Thiếu rule ở ALB thì request từ Internet không vào được → timeout ở phía khách. Thiếu rule ở EC2 thì health check trượt → ALB không có target lành → khách cũng gặp lỗi.

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

• A. "Ứng dụng đã chết" — nếu vậy thì health check trên index.html sẽ trượt, và ALB trả về 503 Service Unavailable, không phải timeout. Đề mô tả timeout, nên vấn đề nằm ở tầng mạng.
• C. "ALB đang khởi động (warming up)" — ALB tự co giãn và không cần pre-warm cho tải thông thường. Và nếu đúng là vấn đề tạm thời thì nó tự hết sau vài phút, không phải thứ cần chẩn đoán.
• D. IAM Roles — kiểm soát quyền của ứng dụng gọi dịch vụ AWS. Nó không tham gia gì vào việc khách truy cập website — không có IAM nào trong đường đi từ trình duyệt tới ALB.

Ghi nhớ

Chẩn đoán theo triệu chứng — bảng rất hữu dụng: | Triệu chứng | Nghi ngờ đầu tiên | |---|---| | Timeout | security group / NACL — gói tin không tới | | 502 Bad Gateway | target trả về phản hồi không hợp lệ, hoặc ứng dụng crash | | 503 Service Unavailable | không có target lành nào đăng ký | | 504 Gateway Timeout | target nhận được request nhưng trả lời quá chậm |

Danh sách kiểm khi website không truy cập được:

1. Security group của ALB: inbound 80/443 từ 0.0.0.0/0
2. Security group của EC2: inbound từ SG của ALB
3. NACL: cho phép cả hai chiều (nhớ ephemeral port 1024–65535)
4. ALB là internet-facing và nằm trong public subnet
5. Target group có target ở trạng thái healthy

Đáp án

A — Lambda dùng Amazon SES gửi email, cấu hình làm post authentication trigger của Cognito user pool.

Vì sao đúng

Yêu cầu: gửi email cho đội bảo mật mỗi khi có người đăng nhập thành cô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, và mốc đúng ở đây là Post authentication — Cognito gọi nó sau khi xác thực thành công, bao gồm cả bước MFA:

def handler(event, context):
    thuoc_tinh = event['request']['userAttributes']
    ses.send_email(
        Source='canh-bao@congty.vn',
        Destination={'ToAddresses': ['bao-mat@congty.vn']},
        Message={
            'Subject': {'Data': 'Đăng nhập mới vào ứng dụng'},
            'Body': {'Text': {'Data':
                f"Người dùng: {event['userName']}\n"
                f"Email: {thuoc_tinh.get('email')}\n"
                f"Thời điểm: {datetime.utcnow().isoformat()}"}}})
    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 tốt nhất: 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 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

• B. Pre authentication trigger — chạy TRƯỚC khi xác thực, tức là trước khi biết đăng nhập có thành công hay không. Nó sẽ báo cả những lần nhập sai mật khẩu — sai ngữ nghĩa "track every user login activity". (Pre authentication dùng để chặn đăng nhập theo điều kiện, ví dụ chặn theo IP.)
• C. Trigger trên identity pool — identity pool không có Lambda trigger. Chỉ user pool mới có. Identity pool chỉ đổi danh tính lấy thông tin xác thực AWS.
• D. Đẩy toàn bộ dữ liệu đăng nhập sang Kinesis Data Streams — nặng nề và vòng vo: dựng một đường ống streaming 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ễ, thêm chi phí, thêm chỗ hỏng.

Ghi nhớ

Các Lambda trigger 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 | | Post confirmation | sau khi xác nhận tài khoản | | Pre token generation | thêm claim tuỳ biến vào token | | Custom message | tuỳ biến nội dung email/SMS | | Define/Create/Verify auth challenge | luồng xác thực tuỳ biến |

Quy tắc chọn: cần biết đăng nhập ĐÃ thành công ⇒ Post authentication. Cần chặn trước khi cho vào ⇒ Pre authentication.

Đáp án

A — Multipart upload kèm S3 Transfer Acceleration.

Vì sao đúng

Đề có hai đặc điểm, và mỗi đặc điểm chọn một nửa của đáp án: tệp 2 GB (lớn) và tải lên từ trung tâm dữ liệu on-premises (ở xa).

Multipart upload — cho tệp lớn: | Lợi ích | Chi tiết | |---|---| | Tải song song | nhiều phần cùng lúc ⇒ tận dụng hết băng thông | | Thử lại theo phần | lỗi mạng chỉ phải gửi lại một phần, không phải cả 2 GB | | Tạm dừng và tiếp tục | được |

AWS khuyến nghị dùng multipart cho tệp trên 100 MB, và bắt buộc cho tệp trên 5 GB.

Transfer Acceleration — cho khoảng cách xa:

Không có TA: on-premises → (Internet công cộng, đường vòng) → S3
Có TA      : on-premises → CloudFront edge gần nhất → (mạng lưng AWS) → S3

Traffic đi vào mạng riêng của AWS ngay tại edge location gần nhất, thay vì đi hết chặng đường trên Internet công cộng. AWS ghi nhận cải thiện 50–500% tuỳ khoảng cách.

Bật rất đơn giản:

aws s3api put-bucket-accelerate-configuration --bucket kho-backup --accelerate-configuration Status=Enabled
aws s3 cp backup.gz s3://kho-backup/ --endpoint-url https://kho-backup.s3-accelerate.amazonaws.com

(AWS CLI tự dùng multipart cho tệp lớn, nên thực tế bạn chỉ cần bật TA.)

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

• D. Chỉ multipart upload — tốt cho tệp lớn nhưng không giải quyết vế khoảng cách. Traffic vẫn đi qua Internet công cộng suốt chặng đường.
• B. Tải lên trong một thao tác duy nhất — chậm nhất, và lỗi mạng giữa chừng là phải làm lại từ đầu với 2 GB. Ngoài ra PutObject đơn lẻ giới hạn 5 GB.
• C. FTP vào một EC2 cùng Region rồi chuyển sang S3 — thêm một chặng hoàn toàn thừa: bạn vẫn phải truyền 2 GB qua Internet tới EC2, và giờ còn thêm chi phí EC2, thêm bước, thêm chỗ hỏng.

Ghi nhớ

Nhớ nhanh: upload chậm ở xa ⇒ Transfer Acceleration; download chậm ở xa ⇒ CloudFront.

Và ba lưu ý về multipart: kích thước phần tối thiểu 5 MB (trừ phần cuối), tối đa 10.000 phần, và nhớ đặt lifecycle rule dọn multipart upload dở dang — chúng chiếm dung lượng và tính tiền mà không hiện ra trong danh sách object.

Đáp án

D — HTTP 503: Service unavailable.

Vì sao đúng

503 là mã mà ALB trả về khi không có target nào lành để chuyển request tới. Nguyên nhân điển hình:

Ý nghĩa của mã này rất chính xác: "máy chủ hiện không thể xử lý request" — ALB hoạt động bình thường, nó chỉ không có ai để chuyển tiếp.

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

Ba mã còn lại đều là lỗi thật của ALB nhưng cho nguyên nhân khác hẳn — và phân biệt được chúng là kỹ năng chẩn đoán rất thực dụng:

• C. 502 Bad Gateway — ALB đã chuyển request tới target, nhưng target trả về phản hồi không hợp lệ: đóng kết nối đột ngột, ứng dụng crash giữa chừng, header sai định dạng, hoặc chứng chỉ TLS của target không hợp lệ.
• B. 504 Gateway Timeout — target nhận được request nhưng không trả lời kịp trong idle timeout của ALB (mặc định 60 giây). Thường là truy vấn CSDL chậm hoặc ứng dụng bị treo.
• A. 500 Internal Server Error — thường do chính ứng dụng sinh ra, hoặc ALB gặp lỗi nội bộ. Không phải mã cho tình huống thiếu target.

Ghi nhớ

Bảng chẩn đoán ALB theo mã lỗi — đáng thuộc: | Mã | Nghĩa | Kiểm tra gì | |---|---|---| | 503 | không có target lành | target đã đăng ký chưa? health check có qua không? | | 502 | target trả về phản hồi hỏng | ứng dụng có crash không? log ứng dụng nói gì? | | 504 | target trả lời quá chậm | truy vấn chậm? tăng idle timeout? | | 500 | lỗi trong ứng dụng hoặc ALB | log ứng dụng | | 400 | request từ client không hợp lệ | — |

Và với 503, danh sách kiểm theo thứ tự:

1. Target group có target nào không?
2. Target ở trạng thái healthy không? (xem Health status details để biết lý do)
3. Security group của instance có cho phép SG của ALB không?
4. Đường dẫn và cổng health check có đúng không?
5. Listener rule có trỏ vào đúng target group không?

Đáp án

B — SSE-C (Server-Side Encryption with Customer-Provided Keys).

Vì sao đúng

Đề nói rõ: server-side encryption với khoá do khách hàng cung cấp — đó chính là định nghĩa của SSE-C.

Với SSE-C, bạn gửi khoá kèm mỗi request; S3 dùng nó để mã hoá hoặc giải mã rồi xoá khoá khỏi bộ nhớ ngay, không lưu lại:

var request = new PutObjectRequest {
    BucketName = "kho-du-lieu",
    Key = "tep.dat",
    FilePath = "tep.dat",
    ServerSideEncryptionCustomerMethod = ServerSideEncryptionCustomerMethod.AES256,
    ServerSideEncryptionCustomerProvidedKey = base64Key
};

Ba header đi kèm mỗi request: | Header | Nội dung | |---|---| | x-amz-server-side-encryption-customer-algorithm | AES256 | | x-amz-server-side-encryption-customer-key | khoá 256-bit mã hoá base64 | | x-amz-server-side-encryption-customer-key-MD5 | MD5 của khoá, để S3 kiểm tra toàn vẹn |

Đề cũng liệt kê đúng bốn thao tác cần khoá: PUT, GET, HEAD, COPY — vì mọi thao tác chạm vào object đều phải có khoá, kể cả HEAD chỉ đọc metadata.

Và một đặc điểm quan trọng: SSE-C bắt buộc dùng HTTPS — S3 từ chối request qua HTTP, vì khoá sẽ đi trần trên đường truyền.

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

• A. SSE-KMS — khoá do KMS quản lý; bạn chỉ định key ID, không cung cấp khoá. Cho kiểm soát và vết CloudTrail, nhưng không khớp yêu cầu "customer-provided".
• C. SSE-S3 — khoá hoàn toàn do S3 quản lý; bạn không kiểm soát gì cả. Càng không khớp.
• D. Client-Side Encryption — dữ liệu được mã hoá TRƯỚC KHI rời khỏi máy bạn. Đây là client-side, không phải server-side như đề yêu cầu. S3 chỉ nhận một khối byte vô nghĩa và không tham gia vào việc mã hoá.

Ghi nhớ

Cảnh báo quan trọng nhất về SSE-C: AWS không lưu khoá của bạn ở bất kỳ đâu. Mất khoá là mất object vĩnh viễn — không có cách nào khôi phục. Đó là lý do SSE-C ít được dùng trong thực tế trừ khi có yêu cầu tuân thủ bắt buộc.