|
| 1 | +### YamlMime:ModuleUnit |
| 2 | +uid: learn.wwl.scale-containers-azure-container-apps.module-assessment |
| 3 | +title: Module assessment |
| 4 | +metadata: |
| 5 | + title: Module Assessment |
| 6 | + description: Module assessment |
| 7 | + ms.date: 01/26/2026 |
| 8 | + author: jeffkoms |
| 9 | + ms.author: jeffko |
| 10 | + ms.topic: unit |
| 11 | +azureSandbox: false |
| 12 | +durationInMinutes: 5 |
| 13 | +content: | |
| 14 | +quiz: |
| 15 | + questions: |
| 16 | + - content: "A developer wants to configure a container app that processes messages from an Azure Service Bus queue and scales to zero replicas when no messages are present. Which scaling configuration meets this requirement?" |
| 17 | + choices: |
| 18 | + - content: "Set `--min-replicas 0` with an HTTP scale rule" |
| 19 | + isCorrect: false |
| 20 | + explanation: "HTTP scale rules monitor HTTP request concurrency, not Service Bus queue depth. To scale based on queue messages, you need a custom Service Bus scale rule." |
| 21 | + - content: "Set `--min-replicas 0` with a CPU scale rule" |
| 22 | + isCorrect: false |
| 23 | + explanation: "CPU scale rules can't scale to zero because the platform requires at least one running replica to measure CPU utilization. CPU-based scaling always maintains a minimum of one replica." |
| 24 | + - content: "Set `--min-replicas 0` with an azure-servicebus scale rule" |
| 25 | + isCorrect: true |
| 26 | + explanation: "The azure-servicebus scale rule monitors queue depth and supports scale-to-zero. When no messages are in the queue, the application can scale to zero replicas. New messages trigger automatic scale-up." |
| 27 | + - content: "A development team wants to ensure their container app has five replicas ready before the morning traffic spike at 8 AM, while still allowing scale-to-zero overnight. Which scaling approach meets this requirement?" |
| 28 | + choices: |
| 29 | + - content: "Configure a cron scale rule combined with an HTTP scale rule" |
| 30 | + isCorrect: true |
| 31 | + explanation: "Cron scaling activates during specified time windows and requests a fixed number of replicas. Combined with HTTP scaling, the cron rule establishes baseline capacity before expected peak hours while HTTP scaling handles variations. Outside the cron window, the app can scale to zero when no traffic arrives." |
| 32 | + - content: "Set minimum replicas to five with an HTTP scale rule" |
| 33 | + isCorrect: false |
| 34 | + explanation: "Setting minimum replicas to five prevents scale-to-zero entirely. The application would maintain five replicas always, including overnight when no traffic arrives, increasing costs unnecessarily." |
| 35 | + - content: "Configure a CPU scale rule with a low utilization threshold" |
| 36 | + isCorrect: false |
| 37 | + explanation: "CPU scale rules can't scale to zero because the platform requires at least one running replica to measure utilization. Additionally, CPU scaling reacts to current load rather than anticipating future demand based on time schedules." |
| 38 | + - content: "A team is deploying a new version of their container app and wants to send 10% of traffic to the new version for validation before full rollout. What must they configure?" |
| 39 | + choices: |
| 40 | + - content: "Enable multiple revision mode and configure traffic splitting with revision weights" |
| 41 | + isCorrect: true |
| 42 | + explanation: "Multiple revision mode allows multiple revisions to be active simultaneously. Traffic splitting with revision weights distributes traffic by percentage, enabling canary deployments where a small percentage of traffic goes to the new version for validation." |
| 43 | + - content: "Use single revision mode with zero-downtime deployment" |
| 44 | + isCorrect: false |
| 45 | + explanation: "Single revision mode only allows one active revision at a time. Zero-downtime deployment shifts all traffic to the new revision once it's ready, without the ability to split traffic between versions." |
| 46 | + - content: "Configure a cron scale rule to schedule traffic shifts" |
| 47 | + isCorrect: false |
| 48 | + explanation: "Cron scale rules control replica count based on time schedules, not traffic distribution. Traffic splitting requires multiple revision mode and explicit traffic weight configuration." |
| 49 | + - content: "When configuring KEDA scale rules for Azure services, which authentication method is recommended for production workloads?" |
| 50 | + choices: |
| 51 | + - content: "Connection strings stored as container app secrets" |
| 52 | + isCorrect: false |
| 53 | + explanation: "While connection strings work for authentication, they require manual secret management and rotation. Managed identity provides a more secure approach for production by eliminating the need to store and rotate credentials." |
| 54 | + - content: "Managed identity with `--scale-rule-identity`" |
| 55 | + isCorrect: true |
| 56 | + explanation: "Managed identity authentication eliminates the need to store connection strings as secrets. The scaler authenticates directly using the identity, reducing security risks, and simplifying credential management for production deployments." |
| 57 | + - content: "Anonymous access without authentication" |
| 58 | + isCorrect: false |
| 59 | + explanation: "Azure services like Service Bus, Event Hubs, and Storage require authentication. Anonymous access isn't supported for these services and would prevent the scaler from accessing the event source." |
0 commit comments