|
| 1 | +### YamlMime:ModuleUnit |
| 2 | +uid: learn.wwl.deploy-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: "You're deploying an AI document-processing API that must access a private endpoint and share logs and networking settings across multiple container apps. Which Azure Container Apps resource provides that shared boundary?" |
| 17 | + choices: |
| 18 | + - content: "A Container Apps environment" |
| 19 | + isCorrect: true |
| 20 | + explanation: "A Container Apps environment is the shared boundary that groups container apps for networking and observability integration, which helps you manage shared settings for a solution." |
| 21 | + - content: "A Container Apps revision" |
| 22 | + isCorrect: false |
| 23 | + explanation: "A revision is a versioned snapshot of a single container app's configuration. It doesn't provide a shared boundary for multiple apps." |
| 24 | + - content: "A replica" |
| 25 | + isCorrect: false |
| 26 | + explanation: "A replica is an instance of a revision that runs your workload. Replicas scale your app, but they don't define shared networking or logging settings across apps." |
| 27 | + - content: "You want a consistent, source-controlled deployment for a container app so that configuration is reviewed like code. Which approach best supports that goal?" |
| 28 | + choices: |
| 29 | + - content: "Use `az containerapp create --yaml` and `az containerapp update --yaml` with a YAML file stored in source control" |
| 30 | + isCorrect: true |
| 31 | + explanation: "Using YAML definitions lets you store configuration in source control and apply it consistently across environments using CLI commands." |
| 32 | + - content: "Use `az containerapp update --set-env-vars` for all changes without maintaining a configuration file" |
| 33 | + isCorrect: false |
| 34 | + explanation: "`--set-env-vars` is useful for incremental updates, but it doesn't provide a durable, reviewable source of truth for the full app configuration." |
| 35 | + - content: "Rely on image tags and redeploy with `az containerapp update --image` to apply environment-specific configuration" |
| 36 | + isCorrect: false |
| 37 | + explanation: "Image tags aren't a reliable configuration mechanism. Configuration should be separated from the image and applied through environment variables, secrets, and app settings." |
| 38 | + - content: "Your container app needs an API key for an embeddings provider. You don't want to store the value in a YAML file. Which pattern should you use?" |
| 39 | + choices: |
| 40 | + - content: "Store the secret in Container Apps secrets and reference it from an environment variable" |
| 41 | + isCorrect: true |
| 42 | + explanation: "This pattern keeps secret values out of source control while still making them available to the running container through a referenced environment variable." |
| 43 | + - content: "Add the API key as plain text in the YAML file under `env:`" |
| 44 | + isCorrect: false |
| 45 | + explanation: "Putting secret values directly in YAML risks exposure in source control and logs. Use secrets instead." |
| 46 | + - content: "Bake the API key into the container image" |
| 47 | + isCorrect: false |
| 48 | + explanation: "Embedding secrets in the image is difficult to rotate and increases the risk of accidental disclosure." |
| 49 | + - content: "You updated a container app and want to confirm the new configuration is running in production. Which command helps you see the versioned change that Container Apps created?" |
| 50 | + choices: |
| 51 | + - content: "Run `az containerapp revision list`" |
| 52 | + isCorrect: true |
| 53 | + explanation: "Container Apps uses revisions to version configuration changes. Listing revisions helps you verify which revision is active after an update." |
| 54 | + - content: "Run `az containerapp registry list`" |
| 55 | + isCorrect: false |
| 56 | + explanation: "Registry configuration helps with image pulls, but it doesn't show which revision is active after an update." |
| 57 | + - content: "Run `az containerapp secret list`" |
| 58 | + isCorrect: false |
| 59 | + explanation: "Secrets can affect app behavior, but listing secrets doesn't show which revision is active or which configuration version is running." |
| 60 | + - content: "A container app fails to start after you update the image. You need fast feedback to diagnose the issue. Which command is the best first step?" |
| 61 | + choices: |
| 62 | + - content: "Run `az containerapp logs show`" |
| 63 | + isCorrect: true |
| 64 | + explanation: "Container logs provide immediate signals such as startup errors, missing environment variables, or authentication failures." |
| 65 | + - content: "Run `az containerapp revision list`" |
| 66 | + isCorrect: false |
| 67 | + explanation: "Revision status is useful context, but logs usually provide the fastest, most actionable error details when the app fails to start." |
| 68 | + - content: "Run `az containerapp replica list`" |
| 69 | + isCorrect: false |
| 70 | + explanation: "Replica state can show whether instances are crashing or restarting, but logs typically point you directly to the root cause." |
0 commit comments