Task 1.2: Implement container-orchestrated solutions

• AWait up to 30 minutes for the platform to refresh the value

  Incorrect

  The 30-minute automatic refresh applies to secrets that reference Key Vault, not to a value stored directly in Container Apps.

• BSwitch the app to multiple revision mode so the change creates a revision

  Incorrect

  Revision mode doesn't change the scope of secrets; secret changes never generate a new revision in either mode.

• CDelete the secret and add it again under a new name

  Incorrect

  That still doesn't restart existing revisions, and any revision referencing the old name would break.

• DRestart the active revision, or deploy a new revision

  Correct

  Secrets are application-scope; existing revisions see a changed secret only after a restart or in a new revision.

Changes under properties.configuration, such as secret values, ingress and revision mode, are application-scope and don't create a revision. Updating or deleting a secret doesn't automatically affect existing revisions; restart them or deploy a new revision.

• ASet the app's revision mode to multiple

  Correct

  Only multiple revision mode keeps several revisions active at once so they can share traffic.

• BAdd an HTTP scale rule with concurrentRequests set to 10

  Incorrect

  A scale rule controls replica counts within a revision, not how traffic is shared between revisions.

• CGive the new revision the suffix canary

  Incorrect

  A revision suffix only names the revision; it doesn't route any traffic to it.

• DDeploy the new image to a second Container Apps environment

  Incorrect

  A separate environment is a different app with a different URL; it doesn't split traffic for the existing app.

• ESet traffic weights of 90 and 10 percent on the two revisions

  Correct

  Traffic splitting distributes requests to the app's URL across active revisions by percentage.

In the default single revision mode, a new revision replaces the old one once it's ready. Multiple revision mode lets you keep both active and assign traffic weights that add up to 100 percent.

• AA custom rule of type azure-servicebus with queueName, namespace and messageCount metadata and its identity set to system

  Correct

  Scale rules for Azure Service Bus, Event Hubs and Queue Storage support managed identity, so no secret is needed.

• BA custom rule of type azure-servicebus whose auth entry maps the connection parameter to a secret holding the connection string

  Incorrect

  This is the secrets-based form, and it requires the connection string the team refuses to store.

• CAn HTTP rule with concurrentRequests set to the expected queue depth

  Incorrect

  HTTP rules scale on concurrent HTTP requests to the revision, not on queue messages, and a queue worker has no such traffic.

• DA custom rule of type cpu with a utilization target of 50 percent

  Incorrect

  A CPU rule reacts to processor load in running replicas, not to the number of messages waiting in the queue, so it misses the requirement.

Container Apps maps any ScaledObject-based KEDA scaler to a custom scale rule: the scaler type, its metadata, and either an auth array that references secrets or, for supported Azure services, an identity ("system" or a user-assigned identity's resource ID).

• AThe Consumption profile, scaling replicas on demand and to zero

  Incorrect

  Consumption replicas top out at 4 vCPU and 8 GiB of memory, far below what this service needs.

• BA Flexible profile (preview)

  Incorrect

  Flexible profiles offer replicas of up to 16 GiB, which is still too small, and are billed like Consumption.

• CA Dedicated memory-optimized profile such as E8 or E16

  Correct

  Dedicated memory-optimized profiles offer 32 to 256 GiB, run on reserved compute and bill per profile instance.

• DA Consumption GPU profile

  Incorrect

  GPU profiles target GPU workloads; this service needs memory, not GPU acceleration.

Workload profiles set the compute available to apps in an environment. Consumption suits bursty, scale-to-zero apps; Dedicated profiles run on reserved nodes in general-purpose, memory-optimized or GPU sizes and are more cost-effective for steady workloads.

• AThe service selector doesn't match the labels on the pods

  Correct

  A service lists as endpoints only the pods whose labels match its selector; an empty list points to a label or selector mismatch.

• BThe application inside the pods listens on 127.0.0.1 instead of 0.0.0.0

  Incorrect

  That makes connections to the pod IP fail, but the pods would still appear as endpoints of the service.

• CA network security group on the node subnet blocks the pod CIDR

  Incorrect

  Blocked traffic causes timeouts, but it doesn't remove the pods from the service's endpoint list.

• DThe service is waiting for Azure to assign an external IP address

  Incorrect

  A ClusterIP service never gets an external IP; that state belongs to a LoadBalancer service.

Troubleshoot AKS connectivity inside out: check the pod, then the service. kubectl describe service shows the endpoints the service sends traffic to; if the pod IPs aren't there, verify the labels and selectors of the pods and the service.

• Akubectl get events --namespace <namespace>

  Incorrect

  Events record lifecycle activity such as back-off and restarts, not the application's own stdout.

• Bkubectl describe node <node-name>

  Incorrect

  Node details show capacity, conditions and scheduled pods, not a container's application output.

• Ckubectl get pods -o wide

  Incorrect

  This lists pod status, IP and node, but no log output.

• Dkubectl logs <pod-name> --previous

  Correct

  The --previous flag returns the logs of the previous container instance, which is the one that crashed.

kubectl describe pod and the cluster events explain why a pod restarts; the container's own output comes from kubectl logs, and --previous selects the instance that ran before the current restart.

• AA hard-coded path to the projected token in the application settings

  Incorrect

  Microsoft advises against hard-coding the token path; the variable is set by the webhook, which hasn't run for this pod.

• BThe Secrets Store CSI Driver add-on on the cluster

  Incorrect

  The CSI driver mounts Key Vault content as files; it isn't needed for workload identity sign-in.

• CAn AcrPull role assignment for the managed identity

  Incorrect

  AcrPull governs image pulls from a registry, not token issuance for Key Vault access.

• DThe label azure.workload.identity/use set to "true" in the pod template

  Correct

  Only pods with this label are mutated by the webhook, which injects the environment variables and the projected token volume.

Workload ID relies on service account token projection and OIDC federation. The azure-workload-identity mutating webhook acts only on pods labeled azure.workload.identity/use: "true"; it then injects AZURE_FEDERATED_TOKEN_FILE and the other variables that DefaultAzureCredential reads.

• AA traffic split that sends 1 percent of the main URL's traffic to the candidate

  Incorrect

  Traffic weights apply to the app's main URL, which must stay unchanged for public users.

• BThe revision-specific FQDN of each candidate revision

  Incorrect

  Each new revision gets a new revision name, so testers would need a new URL every time.

• CA label on the candidate revision, moved to each new candidate

  Correct

  A label gives one revision its own URL, and the URL stays the same when you move the label to another revision.

• DA second container app named candidate in the same environment

  Incorrect

  A separate app means separate deployments and configuration instead of a stable pointer to a revision.

Labels route traffic to a specific revision through a dedicated URL. They work independently of traffic splitting, can be applied to only one revision at a time, and keep the same URL when moved.

• AIt adds a replica when concurrent requests exceed 10, the default

  Correct

  concurrentRequests defaults to 10; above it the revision adds replicas up to maxReplicas.

• BKEDA polls the HTTP metric every 30 seconds

  Incorrect

  The 30-second polling interval applies to event sources; it doesn't apply to HTTP and TCP rules.

• CThe same rule can be attached to a Container Apps job

  Incorrect

  Container Apps jobs don't support HTTP scaling rules.

• DConcurrent requests are computed every 15 seconds from the requests in the past 15 seconds

  Correct

  The platform divides the requests of the past 15 seconds by 15 on a 15-second cycle.

• EIt scales the revision vertically by adding CPU and memory

  Incorrect

  Container Apps scales horizontally by adding replicas; vertical scaling isn't supported.

HTTP rules scale on concurrent requests to the revision. Every 15 seconds the platform calculates them as the past 15 seconds' requests divided by 15 and compares the result with concurrentRequests (default 10).

• AThe service needs type ClusterIP before it can receive an external address

  Incorrect

  ClusterIP is internal only and never gets an external IP.

• BThe pods failed their readiness probes, so the IP is withheld permanently

  Incorrect

  A pending external IP right after creation is normal provisioning, not a probe failure.

• CAn Ingress resource must exist before any service can get an external IP

  Incorrect

  A LoadBalancer service gets its own IP without an Ingress controller.

• DAzure is still provisioning the load balancer's public IP

  Correct

  A LoadBalancer service provisions an Azure load balancer and IP; watch the service until the pending value changes.

LoadBalancer services create an Azure load balancer resource with an external IP and connect the pods to its backend pool. Run kubectl get service <name> --watch until EXTERNAL-IP changes from <pending>.

• ARun kubectl get events with --all-namespaces the next morning

  Incorrect

  The events were already gone; widening the namespace scope doesn't bring back expired events.

• BEnable Container insights to keep the events in Log Analytics

  Correct

  Kubernetes keeps events for only one hour; Container insights collects them for longer retention and querying.

• CRaise the pod's terminationGracePeriodSeconds so events are kept longer

  Incorrect

  That setting controls shutdown time for pods, not event retention.

• DAdd a PodDisruptionBudget so that eviction events are kept longer

  Incorrect

  A PodDisruptionBudget limits voluntary disruptions; it doesn't change how long Kubernetes keeps events.

Events capture the lifecycle of pods, nodes and other objects, with Warning and Normal types. Because Kubernetes has no event retention beyond one hour, enable Container insights to keep and query them.