Container Apps for microservices in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Microservice Communication in Azure Container Apps

You have deployed multiple microservices as Azure Container Apps. You want these microservices to communicate securely within the same environment without exposing them publicly.

Which configuration option ensures secure internal communication between microservices?

A Expose each microservice on a public port and secure with firewall rules.

B Enable ingress with external visibility and use public URLs for communication.

C Use Azure API Management to route traffic between microservices externally.

D Disable ingress and use internal Dapr service invocation between Container Apps.

💡 Hint

Think about how Azure Container Apps enable secure service-to-service calls without public exposure.

Disabling ingress and using Dapr service invocation allows microservices to communicate securely inside the Container Apps environment without exposing endpoints publicly.

❓ Configuration

intermediate

Scaling Microservices in Azure Container Apps

You want to configure automatic scaling for a microservice deployed as an Azure Container App based on HTTP request load.

Which scaling trigger should you configure to scale out the microservice when HTTP requests increase?

A Configure a Dapr pub/sub trigger to scale on message queue length.

B Configure a CPU-based scaling trigger to scale when CPU usage exceeds 70%.

C Configure an HTTP scaling trigger to scale based on concurrent HTTP requests.

D Configure a manual scale setting with fixed instance count.

💡 Hint

Consider which trigger directly relates to HTTP traffic load.

The HTTP scaling trigger automatically scales the Container App based on the number of concurrent HTTP requests, making it ideal for web-based microservices.

❓ security

advanced

Securing Secrets in Azure Container Apps Microservices

You have multiple microservices running as Azure Container Apps that require access to sensitive configuration values like database passwords.

What is the best practice to securely provide these secrets to your microservices?

A Use Azure Key Vault references integrated with Azure Container Apps secrets feature.

B Store secrets in environment variables directly in the Container App configuration.

C Embed secrets in the container image during build time.

D Store secrets in a public GitHub repository and pull them at runtime.

💡 Hint

Think about a secure, managed way to handle secrets without exposing them in code or environment variables.

Azure Container Apps supports integration with Azure Key Vault, allowing secrets to be securely referenced and injected at runtime without exposing them in code or environment variables.

❓ service_behavior

advanced

Observability in Azure Container Apps Microservices

You want to monitor logs and metrics from multiple microservices running as Azure Container Apps to troubleshoot performance issues.

Which Azure service should you configure to collect and analyze telemetry data from your Container Apps?

A Azure Functions to poll Container Apps logs periodically.

B Azure Monitor with Container Insights enabled for Container Apps.

C Azure DevOps pipelines for log collection.

D Azure Blob Storage to store logs manually from each Container App.

💡 Hint

Consider the Azure service designed for monitoring and diagnostics of container workloads.

Azure Monitor with Container Insights provides integrated monitoring, collecting logs and metrics from Container Apps for analysis and troubleshooting.

✅ Best Practice

expert

Designing a Resilient Microservices Architecture with Azure Container Apps

You are designing a microservices architecture using Azure Container Apps. You want to ensure that if one microservice fails, it does not cause the entire application to become unavailable.

Which design approach best supports this resilience?

A Use separate Container Apps for each microservice with independent scaling and health probes.

B Combine all microservices into one monolithic container to reduce network calls.

C Deploy all microservices in a single Container App instance to simplify management.

D Disable health checks to avoid automatic restarts that might cause downtime.

💡 Hint

Think about isolation and independent management of microservices for fault tolerance.

Deploying each microservice as a separate Container App allows independent scaling, health monitoring, and failure isolation, improving overall application resilience.

Practice

1. What is the main benefit of using Azure Container Apps for microservices?

easy

A. They let you run small parts of an app separately and scale them easily.

B. They require you to manage all the servers manually.

C. They combine all app parts into one big container.

D. They only work for apps without any updates.

Solution

1. Step 1: Understand microservices in Azure Container Apps

   Azure Container Apps allow running small, separate parts of an app independently.

2. Step 2: Identify the benefit of scaling and updating

   This setup lets you scale and update parts without affecting the whole app, and Azure manages the servers.

3. Final Answer:

   They let you run small parts of an app separately and scale them easily. -> Option A

4. Quick Check:

   Microservices = separate, scalable parts [OK]

Hint: Microservices run small parts separately for easy scaling [OK]

Common Mistakes:

• Thinking you must manage servers yourself
• Believing all parts run in one container
• Assuming no updates are possible

2. Which of the following is the correct way to define a container app in Azure CLI?

easy

A. az container create --name myapp --resource-group mygroup --image myimage:latest

B. az containerapp deploy --name myapp --resource-group mygroup --image myimage:latest

C. az appcontainer create --name myapp --resource-group mygroup --image myimage:latest

D. az containerapp create --name myapp --resource-group mygroup --image myimage:latest

Solution

1. Step 1: Identify the correct Azure CLI command for Container Apps

   The correct command to create a container app is az containerapp create.

2. Step 2: Check the command syntax

   The command includes the app name, resource group, and image, matching az containerapp create --name myapp --resource-group mygroup --image myimage:latest exactly.

3. Final Answer:

   az containerapp create --name myapp --resource-group mygroup --image myimage:latest -> Option D

4. Quick Check:

   Container Apps use 'az containerapp create' [OK]

Hint: Use 'az containerapp create' to define container apps [OK]

Common Mistakes:

• Using 'az container create' which is for regular containers
• Typing 'appcontainer' instead of 'containerapp'
• Using 'deploy' instead of 'create' command

3. Given this Azure CLI command:

az containerapp create --name orderservice --resource-group shoprg --image shop/orders:1.0 --cpu 0.5 --memory 1.0

What resource limits are set for this container app?

medium

A. 0.5 CPU cores and 1.0 GB memory

B. 1 CPU core and 0.5 GB memory

C. 0.5 CPU cores and 0.5 GB memory

D. 1 CPU core and 1.0 GB memory

Solution

1. Step 1: Read the CPU and memory flags in the command

   The command sets --cpu 0.5 and --memory 1.0.

2. Step 2: Interpret the values

   CPU is 0.5 cores, memory is 1.0 GB as per the flags.

3. Final Answer:

   0.5 CPU cores and 1.0 GB memory -> Option A

4. Quick Check:

   CPU=0.5, Memory=1.0 GB [OK]

Hint: Match --cpu and --memory values exactly [OK]

Common Mistakes:

• Swapping CPU and memory values
• Assuming units are in MB instead of GB
• Ignoring the flags and guessing defaults

4. You tried to deploy a container app with this command:

az containerapp create --name paymentapp --resource-group payrg --image pay/image:latest --cpu two --memory 1.5

What is the likely problem?

medium

A. The memory value 1.5 is too low; it must be at least 2 GB.

B. The CPU value 'two' is invalid; it should be a number like 2 or 0.5.

C. The image tag 'latest' is not allowed in Azure Container Apps.

D. The resource group name 'payrg' is invalid.

Solution

1. Step 1: Check the CPU parameter format

   The CPU value must be a number (like 0.5 or 2), not a word.

2. Step 2: Identify the error in the command

   Using 'two' instead of a numeric value causes a syntax error.

3. Final Answer:

   The CPU value 'two' is invalid; it should be a number like 2 or 0.5. -> Option B

4. Quick Check:

   CPU must be numeric [OK]

Hint: CPU must be a number, not a word [OK]

Common Mistakes:

• Using words instead of numbers for CPU
• Assuming 'latest' tag is invalid
• Thinking resource group name is the problem

5. You want to deploy a microservice architecture using Azure Container Apps with three services: frontend, backend, and database. You want each to scale independently and update without downtime. Which approach is best?

hard

A. Deploy only the frontend as a container app and run backend and database on VMs.

B. Combine all services into one container app to simplify management.

C. Deploy each service as a separate container app with its own scaling rules.

D. Use Azure Container Instances for all services instead of Container Apps.

Solution

1. Step 1: Understand microservice deployment goals

   Each service should scale independently and update without downtime.

2. Step 2: Evaluate deployment options

   Deploying each service as a separate container app allows independent scaling and updates.

3. Step 3: Rule out other options

   Combining services loses independent scaling; mixing VMs adds complexity; Container Instances lack built-in scaling features.

4. Final Answer:

   Deploy each service as a separate container app with its own scaling rules. -> Option C

5. Quick Check:

   Separate apps = independent scaling and updates [OK]

Hint: Separate container apps for each microservice [OK]

Common Mistakes:

• Combining all services in one container app
• Mixing container apps with VMs unnecessarily
• Using Container Instances which lack scaling