Bird
Raised Fist0
Azurecloud~10 mins

Reliability pillar principles in Azure - Interactive Code Practice

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to create an Azure Availability Set for high availability.

Azure
az vm availability-set create --name myAvailabilitySet --resource-group myResourceGroup --[1]
Drag options to blanks, or click blank then click option'
Alocation eastus
Bos-type Linux
Cplatform-fault-domain-count 2
Dvm-sku Standard_DS1_v2
Attempts:
3 left
💡 Hint
Common Mistakes
Using location instead of fault domain count
Specifying VM SKU in availability set creation
2fill in blank
medium

Complete the code to configure Azure Load Balancer health probe.

Azure
az network lb probe create --resource-group myResourceGroup --lb-name myLoadBalancer --name myHealthProbe --protocol tcp --port 80 --[1] 5
Drag options to blanks, or click blank then click option'
Apriority
Bthreshold
Ctimeout
Dinterval
Attempts:
3 left
💡 Hint
Common Mistakes
Confusing interval with timeout
Using threshold instead of interval
3fill in blank
hard

Fix the error in the Azure VM scale set creation command to ensure automatic instance repair is enabled.

Azure
az vmss create --resource-group myResourceGroup --name myScaleSet --image UbuntuLTS --upgrade-policy-mode automatic --[1] true
Drag options to blanks, or click blank then click option'
Aenable-instance-repair
Bautomatic-repairs-enabled
Cenable-auto-repair
Dautomatic-instance-repair
Attempts:
3 left
💡 Hint
Common Mistakes
Using incorrect parameter names that don't exist
Confusing instance repair with upgrade policy
4fill in blank
hard

Fill both blanks to create an Azure Storage Account with geo-redundant replication and enable soft delete.

Azure
az storage account create --name mystorageaccount --resource-group myResourceGroup --sku [1] --kind StorageV2
az storage account update --name mystorageaccount --resource-group myResourceGroup --[2] true
Drag options to blanks, or click blank then click option'
AStandard_GRS
BStandard_LRS
Cenable-soft-delete
Denable-delete-retention
Attempts:
3 left
💡 Hint
Common Mistakes
Using locally redundant storage instead of geo-redundant
Confusing soft delete with retention policies
5fill in blank
hard

Fill all three blanks to define an Azure Monitor alert rule that triggers when CPU usage exceeds 80% for 5 minutes.

Azure
az monitor metrics alert create --name HighCPUAlert --resource-group myResourceGroup --scopes [1] --condition "avg '[2]' > [3]" --description "Alert when CPU > 80%"
Drag options to blanks, or click blank then click option'
A/subscriptions/12345/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM
BPercentage CPU
C80
DCPU Usage
Attempts:
3 left
💡 Hint
Common Mistakes
Using incorrect resource ID format
Using wrong metric name or threshold value

Practice

(1/5)
1. Which of the following best describes the main goal of the Reliability pillar in cloud architecture?
easy
A. Ensure applications run without interruption and recover quickly from failures
B. Maximize the speed of application deployment
C. Reduce the cost of cloud resources
D. Improve the visual design of the application interface

Solution

  1. Step 1: Understand the reliability pillar purpose

    The reliability pillar focuses on keeping applications running smoothly and handling failures gracefully.
  2. Step 2: Compare options with the pillar goal

    Only Ensure applications run without interruption and recover quickly from failures matches the goal of uninterrupted operation and quick recovery.
  3. Final Answer:

    Ensure applications run without interruption and recover quickly from failures -> Option A
  4. Quick Check:

    Reliability = uninterrupted and quick recovery [OK]
Hint: Reliability means apps stay up and fix themselves fast [OK]
Common Mistakes:
  • Confusing reliability with cost savings
  • Thinking reliability is about app speed or design
  • Mixing reliability with security or performance pillars
2. Which Azure service is primarily used to automatically recover from failures and maintain application availability?
easy
A. Azure Availability Zones
B. Azure Blob Storage
C. Azure DevTest Labs
D. Azure Logic Apps

Solution

  1. Step 1: Identify service for failure recovery

    Azure Availability Zones are designed to keep apps running by spreading resources across isolated locations.
  2. Step 2: Eliminate unrelated services

    Blob Storage is for data, DevTest Labs for testing, Logic Apps for workflows, none focus on recovery.
  3. Final Answer:

    Azure Availability Zones -> Option A
  4. Quick Check:

    Recovery and availability = Availability Zones [OK]
Hint: Availability Zones protect apps by spreading resources [OK]
Common Mistakes:
  • Choosing storage or workflow services instead of availability features
  • Confusing testing environments with reliability tools
3. Consider this Azure setup: A web app is deployed across two Availability Zones with automatic failover configured. If one zone goes down, what happens?
medium
A. The app stops working until the zone is restored
B. Users must manually switch to a backup URL
C. The app data is lost permanently
D. Traffic automatically shifts to the healthy zone without downtime

Solution

  1. Step 1: Understand multi-zone deployment with failover

    Deploying across zones with failover means if one zone fails, traffic moves to the other automatically.
  2. Step 2: Analyze options for failover behavior

    Only Traffic automatically shifts to the healthy zone without downtime describes automatic traffic shift with no downtime, matching failover design.
  3. Final Answer:

    Traffic automatically shifts to the healthy zone without downtime -> Option D
  4. Quick Check:

    Failover = automatic traffic shift [OK]
Hint: Failover means traffic moves automatically to healthy zone [OK]
Common Mistakes:
  • Assuming app stops or data is lost on zone failure
  • Thinking manual user action is needed for failover
4. You configured Azure Backup for your virtual machines but notice backups are failing. What is the most likely cause?
medium
A. The VM has no public IP address
B. The VM is running in an Availability Zone
C. Backup vault is not linked to the VM resource group
D. Backup is scheduled during off-peak hours

Solution

  1. Step 1: Check backup configuration requirements

    Azure Backup requires the backup vault to be linked correctly to the VM's resource group for successful backups.
  2. Step 2: Evaluate other options

    Running in Availability Zone, scheduling time, or public IP do not prevent backups.
  3. Final Answer:

    Backup vault is not linked to the VM resource group -> Option C
  4. Quick Check:

    Backup fails if vault not linked properly [OK]
Hint: Backup needs vault linked to VM group [OK]
Common Mistakes:
  • Blaming zones or IP addresses for backup failure
  • Assuming schedule time causes failure
5. You want to design an Azure solution that automatically scales out when demand increases and recovers quickly from failures. Which combination of services best supports these reliability principles?
hard
A. Azure Virtual Machines with manual scaling and Azure Backup
B. Azure App Service with Auto Scale and Azure Traffic Manager
C. Azure Blob Storage with Azure Functions and Azure DevTest Labs
D. Azure Logic Apps with static IP and Azure Monitor

Solution

  1. Step 1: Identify services for automatic scaling and failover

    Azure App Service supports Auto Scale to handle demand changes, and Traffic Manager directs traffic for failover.
  2. Step 2: Eliminate options lacking auto scaling or failover

    Manual scaling or unrelated services do not meet both requirements.
  3. Final Answer:

    Azure App Service with Auto Scale and Azure Traffic Manager -> Option B
  4. Quick Check:

    Auto Scale + Traffic Manager = scaling and recovery [OK]
Hint: Auto Scale + Traffic Manager = scale and recover fast [OK]
Common Mistakes:
  • Choosing manual scaling instead of auto scaling
  • Confusing storage or testing services with reliability tools