Learning Path review questions: LP05

Learning Path review questions

01. What benefits can you achieve by modularizing your infrastructure and configuration resources?

Modularizing infrastructure and configuration resources in Infrastructure as Code (IaC) offers several key benefits:

1. Reusability: You can reuse modules across different projects, environments, or teams. This reduces duplication of effort and ensures consistency across multiple deployments.

2. Maintainability: By breaking down infrastructure into smaller, manageable pieces (modules), it’s easier to update, troubleshoot, and maintain the resources over time. You can make changes to individual modules without impacting the entire infrastructure.

3. Scalability: Modularization allows for easier scaling of resources by reusing and composing smaller, well-defined modules. This makes it simpler to scale components independently.

4. Collaboration: Different teams or stakeholders can work on separate modules concurrently, leading to better collaboration and separation of concerns.

5. Testing: Modules can be tested individually, ensuring that each part of the infrastructure behaves as expected before being integrated into the larger system.

6. Consistency: By defining common resources or configurations as reusable modules, you ensure consistent deployments across environments and reduce the risk of errors.

02. Which method of approach for implementing Infrastructure as Code states what the final state of an environment should be without defining how it should be achieved?

The method of approach where you define what the final state of the environment should be, but not how to achieve it, is called Declarative infrastructure management.

Declarative IaC focuses on the desired end state of the infrastructure. You describe the final configuration of your resources (e.g., “I want a virtual machine with these specs”), and the tool (e.g., Azure Resource Manager, Terraform, etc.) automatically figures out the steps to make that happen.

Example:

In Azure Bicep, you would define the final state of resources, like this:

xxxxxxxxxx
9
1
resource myVm 'Microsoft.Compute/virtualMachines@2021-03-01' = {
2
  name: 'myVM'
3
  location: 'East US'
4
  properties: {
5
    hardwareProfile: {
6
      vmSize: 'Standard_DS1_v2'
7
    }
8
  }
9
}

In this case, you describe the final state of the virtual machine but don't specify how Azure should go about provisioning it.

03. Which term defines the ability to apply one or more operations against a resource, resulting in the same outcome every time?

This ability is referred to as Idempotency.

Idempotency ensures that no matter how many times an operation is performed, the outcome remains the same. If you apply an operation repeatedly (e.g., running a deployment or a configuration change), the result will be consistent each time, meaning the infrastructure will be in the desired state regardless of previous changes or attempts.

Example:

If you deploy a virtual machine with a specific configuration, running the same deployment multiple times won’t create multiple VMs; it will only result in the same VM being configured as defined.

04. Which term is the process whereby a set of resources change their state over time from their original state in which they were deployed?

This process is called Drift.

Drift occurs when the actual state of the resources diverges from the expected state as defined in your Infrastructure as Code templates. Drift can happen due to manual changes, configuration changes, or updates outside of the IaC process.

Tools like Terraform, Azure Policy, or Azure Resource Manager can help detect and remediate drift by comparing the deployed state to the desired configuration.

05. Which Resource Manager deployment mode only deploys whatever is defined in the template, and does not remove or modify any other resources not defined in the template?

The deployment mode you're referring to is Incremental mode in Azure Resource Manager (ARM).

Incremental Deployment Mode: When using this mode, only the resources defined in the template are created, updated, or replaced. Any existing resources in the resource group that are not defined in the template are left untouched (they are not deleted or modified).

This is in contrast to Complete mode, which would remove any resources that are not specified in the template.

Example:

If your template creates a new storage account and an Azure Function, and you deploy it in incremental mode, only those two resources will be affected. Any other resources in the resource group (not defined in the template) will remain unaffected.

06. How are the dependencies defined in a .bicep file?

In a .bicep file, dependencies between resources can be defined using the dependsOn property.

dependsOn explicitly defines the order in which resources should be deployed. By default, Bicep infers dependencies based on resource references, but if needed, you can manually specify the order of resource deployment.

Example:

xxxxxxxxxx
11
1
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = {
2
  name: 'myStorageAccount'
3
  location: 'East US'
4
}
5
resource virtualMachine 'Microsoft.Compute/virtualMachines@2021-03-01' = {
6
  name: 'myVM'
7
  location: 'East US'
8
  dependsOn: [
9
    storageAccount
10
  ]
11
}

In this example, the virtual machine (myVM) will be deployed only after the storage account (myStorageAccount) has been successfully created.

07. What is the behavior of the webAppName parameter for a team that created a template that contains this line:

xxxxxxxxxx
1
1
param webAppName string = 'mySite${uniqueString(resourceGroup().id)}'

In this case, the webAppName parameter will have a default value set to 'mySite' followed by a unique string generated based on the resource group ID.

The uniqueString function generates a deterministic unique value based on the input (here, the resource group ID).

The resulting string will ensure that the webAppName is unique across different deployments, preventing naming conflicts.

For example, if the resource group ID is abcd1234, the webAppName might resolve to mySiteabcd1234. This makes sure that the name is both unique and consistent across deployments of the same template in the same resource group.

08. How can you reuse a Bicep template in other Bicep templates?

You can reuse a Bicep template in other Bicep templates by using modules. Modules in Bicep allow you to encapsulate reusable code into separate files and call them from other Bicep templates.

Example of how to reuse a Bicep template:

Create a reusable module (e.g., storageAccount.bicep):

xxxxxxxxxx
6
1
// storageAccount.bicep
2
param storageAccountName string
3
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = {
4
  name: storageAccountName
5
  location: 'East US'
6
}

Call the module in a parent Bicep file:

xxxxxxxxxx
7
1
// main.bicep
2
module storage 'storageAccount.bicep' = {
3
  name: 'myStorageDeployment'
4
  params: {
5
    storageAccountName: 'myUniqueStorageAccount'
6
  }
7
}

In this example:

The storageAccount.bicep module is reusable.

The main.bicep template imports the module and provides the necessary parameters (storageAccountName) for deployment.

This modular approach enables code reuse and simplifies management by keeping individual pieces of infrastructure separate and more maintainable.