Ngân hàng đề — Microsoft Azure Developer

Đáp án

B — Bảo đảm client LUÔN được định tuyến tới CÙNG một instance trong suốt phiên làm việc.

Vì sao đúng

⚠ ARR Affinity dùng cookie để ghim phiên vào một instance:

⚠ Client gửi request đầu tiên
        ↓
⚠ App Service gán cookie ARRAffinity
        ↓
⚠ Mọi request sau đó
   ⚠ đi tới ĐÚNG instance đó

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

• C (giữ app luôn được tải kể cả không có lưu lượng) — ⚠ đó là ALWAYS ON, thiết lập nằm ngay cạnh.

• D (yêu cầu chứng chỉ client) — ⚠ đó là Client Certificates.

• A (tham số dòng lệnh cho script processor) — ⚠ thiết lập khác trong cùng trang.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ ba phương án nhiễu ⚠ đều là thiết lập THẬT ở cùng trang General Settings — ⚠ đề kiểm tra bạn có phân biệt được chúng không.

⚠ Vì sao nên TẮT ARR Affinity nếu có thể: | Lý do | Nội dung | |---|---| | ⚠ Tải phân bổ KHÔNG đều giữa các instance | | | ⚠ Instance bị khởi động lại là mất phiên | | | ⚠ Cản trở việc co giãn hiệu quả | | | ⚠ Điều kiện để tắt | ⚠ ứng dụng phải STATELESS, session lưu ở Redis hoặc CSDL | | ⚠ Đây là | ⚠ điều kiện tiên quyết để scale out hiệu quả — xem #21479 |

Từ khoá nhận diện:

"giữ client ở cùng instance" → ⚠ ARR Affinity "session affinity, sticky session" → ⚠ cùng khái niệm "giữ app luôn chạy" → ⚠ Always On "cookie ARRAffinity" → ⚠ dấu hiệu nhận biết trong trình duyệt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có lưu session trong bộ nhớ không | | | ARR Affinity có đang bật không và có cần thiết không | | | Tải có phân bổ đều giữa các instance không | |

Và dấu hiệu cho thấy ứng dụng chưa sẵn sàng cho việc mở rộng ngang: nó vẫn cần ARR Affinity để hoạt động đúng. Chuyển session ra kho ngoài là bước đầu tiên để tắt được nó.

Đáp án

D — Nhất quán mạnh nghĩa là trên toàn thế giới, người đọc được BẢO ĐẢM luôn nhận được phiên bản đã commit MỚI NHẤT của một mục dữ liệu.

Vì sao đúng

⚠ Strong consistency là mức bảo đảm cao nhất:

⚠ Ghi ở vùng A
        ↓ ⚠ chưa xác nhận cho tới khi
⚠ Mọi bản sao đã đồng bộ
        ↓
⚠ Đọc ở BẤT KỲ vùng nào
   ⚠ đều thấy giá trị mới nhất
        ↓
⚠ Không bao giờ đọc được dữ liệu cũ

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

• A (hai ứng dụng có thể đọc cùng lúc và thấy khác nhau) — ⚠ mô tả nhất quán YẾU, ngược với strong.

• C (người ghi sau thắng) — ⚠ là chính sách giải quyết XUNG ĐỘT, không phải định nghĩa nhất quán.

• B (cam kết chỉ dùng Cosmos DB một cách duy nhất) — ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp với #21472 trong cùng lô.

⚠ Năm mức nhất quán — bảng chốt: | Mức | Bảo đảm | |---|---| | ⚠ Strong | ⚠ luôn đọc bản mới nhất — mọi nơi | | ⚠ Bounded staleness | ⚠ chậm tối đa N phiên bản hoặc T giây | | ⚠ Session | ⚠ đọc được thứ CHÍNH BẠN vừa ghi — mặc định | | ⚠ Consistent prefix | ⚠ không đọc lộn thứ tự ghi | | ⚠ Eventual | ⚠ cuối cùng sẽ hội tụ, không hứa gì thêm |

Từ khoá nhận diện:

"luôn mới nhất, mọi nơi" → ⚠ Strong "chậm tối đa N giây" → ⚠ Bounded staleness "đọc được thứ mình vừa ghi" → ⚠ Session "cuối cùng sẽ giống nhau" → ⚠ Eventual

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mức mặc định của tài khoản là gì | | | Có đang dùng Strong cho mọi thứ không | ⚠ rất tốn RU | | Có ghi đa vùng không | ⚠ thì Strong không dùng được |

Và điều làm Cosmos DB khác biệt so với phần lớn cơ sở dữ liệu phân tán khác: nó không ép bạn chọn một điểm cố định trên trục nhất quán, mà cho năm mức và cho phép nâng lên ở từng truy vấn cụ thể.

Đáp án

D — ARM Templates.

Vì sao đúng

⚠ ARM template là công nghệ hạ tầng dạng mã gốc của Azure: | Đặc điểm | Nội dung | |---|---| | ⚠ Mô tả hạ tầng bằng tệp JSON | | | ⚠ Đưa vào Git, review như mã | | | ⚠ Khai báo, idempotent | | | ⚠ Azure tự lo thứ tự tạo | | | ⚠ Bicep là cú pháp gọn hơn, biên dịch ra ARM | |

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

• C (GitHub Actions) — ⚠ là công cụ CI/CD: ⚠ nó ⚠ CHẠY template, ⚠ nhưng bản thân không mô tả hạ tầng.

• A (Azure Automation Accounts) — ⚠ chạy runbook để tự động hoá tác vụ vận hành, không phải IaC khai báo.

• B (Visual Studio Enterprise) — ⚠ là IDE.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư về ARM template qua hai lô.

⚠ Các lựa chọn IaC cho Azure: | Công cụ | Đặc điểm | |---|---| | ⚠ ARM template (JSON) | ⚠ gốc, rườm rà | | ⚠ Bicep | ⚠ gọn hơn nhiều, khuyến nghị cho Azure | | ⚠ Terraform | ⚠ đa đám mây, cần state file | | ⚠ Pulumi | ⚠ viết bằng ngôn ngữ lập trình thật | | ⚠ CI/CD chạy chúng | ⚠ GitHub Actions, Azure DevOps |

Từ khoá nhận diện:

"hạ tầng dạng mã trên Azure" → ⚠ ARM template hoặc Bicep "đa đám mây" → ⚠ Terraform "chạy pipeline" → ⚠ GitHub Actions, Azure DevOps "runbook tự động hoá vận hành" → ⚠ Automation Account

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạ tầng có được mô tả bằng mã không | | | Có nên chuyển từ ARM JSON sang Bicep không | | | Dev và prod có dùng chung template không | |

Và phân biệt cần rõ khi trả lời nhóm câu hỏi này: template là thứ MÔ TẢ hạ tầng, còn pipeline là thứ CHẠY nó. Cả hai đều cần, nhưng chúng trả lời hai câu hỏi khác nhau.

Đáp án

D — Azure Blob Lifecycle Management

Vì sao đúng

Lifecycle management cho khai luật tự động theo tuổi của blob hoặc thời điểm truy cập cuối: chuyển xuống tầng lạnh hơn, đưa vào Archive, hoặc xoá hẳn. Luật chạy hằng ngày ở phía dịch vụ, nên không cần ai nhớ làm và không cần viết mã nào.

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

• A. Soft Delete — làm điều ngược lại: giữ blob đã xoá thêm một thời gian để khôi phục. Nó là lưới an toàn, không phải cơ chế dọn dẹp.
• B. Snapshot — chụp bản tại một thời điểm; càng dùng thì càng tốn thêm dung lượng.
• C. Blob Indexing — gắn thẻ để tìm kiếm blob theo thuộc tính; nó giúp tìm chứ không xoá.

Đáp án

A — LRS (Locally Redundant Storage).

Vì sao đúng

⚠ LRS là mức nhân bản đơn giản nhất nên rẻ nhất: | Mức | Bản sao | Phạm vi | Giá | |---|---|---|---| | ⚠ LRS | ⚠ 3 | ⚠ một trung tâm dữ liệu | ⚠ RẺ NHẤT | | ⚠ ZRS | ⚠ 3 | ⚠ ba zone | ⚠ cao hơn | | ⚠ GRS | ⚠ 6 | ⚠ hai vùng | ⚠ cao hơn nữa | | ⚠ GZRS | ⚠ 6 | ⚠ zone + vùng | ⚠ cao nhất |

⚠ Càng nhiều bản sao, càng xa nhau
        ↓
⚠ Càng chịu được sự cố lớn
        ↓
⚠ Càng đắt

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

• D (ZRS), C (GRS), B (GZRS) — ⚠ đều đắt hơn LRS.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ TRÙNG với #19596 ở lô 166.

⚠ Tổng kết năm câu trùng của lô 168: | Câu | Trùng với | Chữ cái đổi | |---|---|---| | ⚠ #21435 (ZRS 3 bản) | ⚠ #19512 | ⚠ A → C | | ⚠ #21463 (Gremlin) | ⚠ #19602 | ⚠ C → B | | ⚠ #21469 (GRS 6 bản) | ⚠ #19562 | ⚠ D → B | | ⚠ #21475 (một API mỗi account) | ⚠ #19581 | ⚠ A → C | | ⚠ #21488 (LRS rẻ nhất) | ⚠ #19596 | ⚠ A → A | | ⚠ Kết luận | ⚠ bốn trong năm câu ĐỔI chữ cái — không thể học thuộc vị trí |

⚠ Mẹo nhớ bảng nhân bản: | Mẹo | Nội dung | |---|---| | ⚠ Không có chữ G | ⚠ 3 bản, một vùng | | ⚠ Có chữ G | ⚠ 6 bản, hai vùng | | ⚠ Có chữ Z | ⚠ trải qua availability zone | | ⚠ Có RA- | ⚠ đọc được ở vùng phụ |

Từ khoá nhận diện:

"rẻ nhất" → ⚠ LRS "chịu mất một zone" → ⚠ ZRS "chịu mất cả vùng" → ⚠ GRS trở lên "đọc ở vùng phụ" → ⚠ RA-

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Môi trường dev có đang dùng mức đắt hơn cần thiết không | | | Dữ liệu có tái tạo được không | | | Đã có soft delete và versioning chưa | |

Và bài học lớn nhất mà năm câu trùng lặp của lô này dạy được: bốn trong năm câu có đáp án ở chữ cái KHÁC so với lần xuất hiện trước. Ghi nhớ nội dung là cách duy nhất, và cũng là cách hiệu quả nhất.

Đáp án

B — Deployment Slots

Vì sao đúng

Deployment slot cho phép triển khai phiên bản mới lên một slot dàn dựng riêng, kiểm thử ở đó, rồi hoán đổi (swap) với slot production. Hoán đổi là thao tác đổi định tuyến nên diễn ra gần như tức thì và không mất kết nối.

Điểm quan trọng nhất với câu hỏi này: quay lui cũng chỉ là hoán đổi ngược lại. Phiên bản cũ vẫn nằm nguyên trong slot kia, nên khôi phục tính bằng giây chứ không phải triển khai lại.

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

• C. Auto Heal — tự khởi động lại ứng dụng khi gặp điều kiện xấu; nó không đưa về phiên bản cũ.
• A. Always On — giữ ứng dụng không bị ngủ, giải bài toán khởi động lạnh.
• D. Application Insights — giúp phát hiện sự cố sau khi phát hành, nhưng không phải cơ chế quay lui.

Đáp án

C — Đúng MỘT.

Vì sao đúng

⚠ Trigger là thứ KHỞI ĐỘNG hàm, nên bắt buộc phải có đúng một: | Loại binding | Số lượng | |---|---| | ⚠ Trigger | ⚠ ĐÚNG 1 — bắt buộc | | ⚠ Input binding | ⚠ 0 tới nhiều | | ⚠ Output binding | ⚠ 0 tới nhiều |

⚠ Không có trigger
   ⚠ → không có gì gọi hàm
⚠ Hai trigger
   ⚠ → nền tảng không biết dùng cái nào
        ↓
⚠ Đúng một là ràng buộc bắt buộc

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

• A (bao nhiêu cũng được) và D (0 hoặc 1) — ⚠ là quy tắc của INPUT BINDING, không phải trigger.

• B (tối đa 32) — ⚠ con số bịa.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp ĐỐI XỨNG với #21406 ở lô trước.

⚠ Bảng quy tắc — chốt lại: | Loại | Số lượng | Bắt buộc | |---|---|---| | ⚠ Trigger | ⚠ 1 | ⚠ CÓ | | ⚠ Input | ⚠ 0 tới n | ⚠ không | | ⚠ Output | ⚠ 0 tới n | ⚠ không |

Từ khoá nhận diện:

"trigger" → ⚠ đúng một, bắt buộc "input binding" → ⚠ bao nhiêu cũng được "direction" → ⚠ in, out, inout "function.json" → ⚠ nơi khai binding

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có đúng một trigger chưa | | | Logic nghiệp vụ có tách khỏi hàm không | ⚠ để kiểm thử được | | Đề đang hỏi trigger hay binding | |

Và cách tổ chức mã Azure Functions giúp việc kiểm thử dễ hơn hẳn: hàm chỉ là lớp vỏ mỏng gọi vào logic nghiệp vụ nằm ở lớp riêng. Khi đó bạn kiểm thử được toàn bộ nghiệp vụ mà không cần chạy Azure.

Đáp án

A — Cache-aside pattern.

Vì sao đúng

⚠ Cache-aside là mẫu kinh điển để tăng tốc bằng cache:

⚠ Ứng dụng cần dữ liệu
        ↓
⚠ 1. Hỏi CACHE trước
        ↓ ⚠ có (cache hit)
⚠    → trả về ngay
        ↓ ⚠ không có (cache miss)
⚠ 2. Đọc từ CSDL
⚠ 3. GHI vào cache
⚠ 4. Trả về cho người gọi

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

• D (Static content hosting) — ⚠ đưa nội dung tĩnh ra CDN hoặc blob: ⚠ cũng tăng hiệu năng nhưng ⚠ không dùng dịch vụ cache.

• B (Sharding) — ⚠ chia dữ liệu qua nhiều kho để mở rộng.

• C (Sidecar) — ⚠ mẫu container: ⚠ chạy tiến trình phụ cạnh ứng dụng chính.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ khép lại chùm bốn câu về Redis và cache trong hai lô.

⚠ Bốn mẫu cache — phân biệt: | Mẫu | Nội dung | |---|---| | ⚠ Cache-aside | ⚠ ứng dụng tự nạp khi miss — phổ biến nhất | | ⚠ Read-through | ⚠ cache tự nạp từ CSDL | | ⚠ Write-through | ⚠ ghi vào cache và CSDL cùng lúc | | ⚠ Write-behind | ⚠ ghi cache trước, CSDL sau — rủi ro mất dữ liệu |

Từ khoá nhận diện:

"hỏi cache trước, miss thì đọc CSDL" → ⚠ cache-aside "chia dữ liệu qua nhiều kho" → ⚠ sharding "container phụ chạy cạnh ứng dụng" → ⚠ sidecar "đưa ảnh và CSS ra CDN" → ⚠ static content hosting

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cache có TTL không | | | Cập nhật dữ liệu có xoá khoá cache tương ứng không | | | Ứng dụng có chạy đúng khi cache trống không | ⚠ nguyên tắc quan trọng nhất |

Và nguyên tắc bất di bất dịch của mẫu cache-aside, cũng là điều phân biệt một hệ thống có cache tốt với một hệ thống phụ thuộc cache: ứng dụng phải hoạt động đúng khi cache hoàn toàn trống rỗng.

Đáp án

A — Dữ liệu tương đối TĨNH.

Vì sao đúng

⚠ Cache có lợi khi tỉ lệ ĐỌC trên GHI cao:

⚠ Dữ liệu tĩnh
   ⚠ ghi một lần, đọc hàng nghìn lần
        ↓
⚠ Nạp vào cache một lần
⚠ Phục vụ rất nhiều lượt đọc
        ↓
⚠ Tỉ lệ trúng cache CAO

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

• B (dữ liệu thay đổi liên tục) — ⚠ NGƯỢC: ⚠ cache liên tục bị vô hiệu, ⚠ tỉ lệ trúng thấp, ⚠ tốn công đồng bộ mà không được lợi.

• C (ghi mà không bao giờ đọc, như log) — ⚠ cache vô nghĩa: ⚠ không có ai đọc lại.

• D (dùng một lần rồi thôi, như mật khẩu) — ⚠ cache cũng vô nghĩa: ⚠ không tái sử dụng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ mở đầu chùm về cache và nối tiếp #21437, #21453, #21491 ở lô trước.

⚠ Ba tiêu chí đánh giá dữ liệu có nên cache: | Tiêu chí | Nội dung | |---|---| | ⚠ Tỉ lệ ĐỌC / GHI | ⚠ càng cao càng đáng cache | | ⚠ Chi phí tạo ra dữ liệu | ⚠ truy vấn nặng thì đáng cache | | ⚠ Mức chấp nhận dữ liệu cũ | ⚠ phải chấp nhận được vài giây tới vài phút | | ⚠ Cả ba đều thoả | ⚠ cache mang lại lợi ích rõ rệt |

Từ khoá nhận diện:

"tĩnh, đọc nhiều ghi ít" → ⚠ hợp cache "thay đổi liên tục" → ⚠ không hợp cache "ghi mà không đọc" → ⚠ không hợp cache "dùng một lần" → ⚠ không hợp cache

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ trúng cache là bao nhiêu | ⚠ dưới 80% thì xem lại | | Dữ liệu này đọc gấp bao nhiêu lần ghi | | | Có dữ liệu nhạy cảm nào đang nằm trong cache không | |

Và chỉ số duy nhất cho biết một cache có đáng tồn tại hay không: tỉ lệ trúng cache. Nếu nó thấp, bạn đang trả tiền cho một tầng trung gian chỉ làm hệ thống phức tạp thêm.

Đáp án

A — Ba.

Vì sao đúng

⚠ Số máy ảo do App Service Plan quyết định, KHÔNG phụ thuộc số app hay số slot:

⚠ App Service Plan
   ⚠ scale out = 3 instance
        ↓
⚠ BA máy ảo
        ↓
⚠ Trên đó chạy:
   ⚠ 5 ứng dụng
   ⚠ mỗi ứng dụng 2 slot
   ⚠ = 10 "site"
        ↓
⚠ Tất cả DÙNG CHUNG ba máy ảo đó

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

• B (mười) — ⚠ bẫy chính: ⚠ nhân 5 app × 2 slot; ⚠ nhưng slot ⚠ không tạo thêm máy ảo.

• D (năm) — ⚠ nhầm số app thành số VM.

• C (một) — ⚠ bỏ qua việc đã scale out lên ba.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ kiểm tra hiểu biết ở #21448 và #21479 theo cách rất thực tế.

⚠ Hệ quả về chi phí — điểm rất quan trọng: | Hệ quả | Nội dung | |---|---| | ⚠ Thêm app vào plan có sẵn: KHÔNG tốn thêm | ⚠ về chi phí hạ tầng | | ⚠ Thêm slot: KHÔNG tốn thêm | | | ⚠ Tăng instance: TỐN thêm | | | ⚠ Nâng bậc plan: TỐN thêm | | | ⚠ Đây là | ⚠ cách tiết kiệm quan trọng nhất của App Service |

Từ khoá nhận diện:

"bao nhiêu VM" → ⚠ theo số instance của PLAN "thêm app có tốn thêm không" → ⚠ không, nếu dùng chung plan "deployment slot có tốn thêm không" → ⚠ không "scale out" → ⚠ tăng số instance, có tốn thêm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu app và slot trên cùng một plan | | | Plan có đủ tài nguyên cho tất cả không | | | App quan trọng có nên tách plan riêng không | |

Và cách tiết kiệm chi phí App Service hiệu quả nhất, xuất phát trực tiếp từ cách tính tiền: gom nhiều ứng dụng nhỏ vào chung một plan. Bạn trả tiền cho hạ tầng, không phải cho số lượng ứng dụng.