Microsoft - AZ-305: Designing Microsoft Azure Infrastructure Solutions

Sample Questions

• Use the same scaling mechanism as the current deployment.
• Support kubenet and Azure Container Networking Interface (CNI) networking.

Explanation:

In the Consumption and Premium plans, Azure Functions scales CPU and memory resources by adding more instances of the Functions host. The number of instances is determined on the number of events that trigger a function.

To use the same scaling mechanism as the current deployment, we should make use of the the horizontal pod autoscaler and kubernetes-based Event Driven Autoscaling (KEDA).

Azure virtual networks

In AKS, you can deploy a cluster that uses one of the following network models:

• Kubenet networking

  The network resources are typically created and configured as the AKS cluster is deployed.

• Azure Container Networking Interface (CNI) networking

  The AKS cluster is connected to existing virtual network resources and configurations.

Kubenet (basic) networking

The kubenet networking option is the default configuration for AKS cluster creation. With kubenet:

1. Nodes receive an IP address from the Azure virtual network subnet.
2. Pods receive an IP address from a logically different address space than the nodes' Azure virtual network subnet.
3. Network address translation (NAT) is then configured so that the pods can reach resources on the Azure virtual network.
4. The source IP address of the traffic is translated to the node's primary IP address.

Nodes use the kubenet Kubernetes plugin. You can let the Azure platform create and configure the virtual networks for you, or choose to deploy your AKS cluster into an existing virtual network subnet.

Only the nodes receive a routable IP address. The pods use NAT to communicate with other resources outside the AKS cluster. This approach reduces the number of IP addresses you need to reserve in your network space for pods to use.

Azure CNI (advanced) networking

With Azure CNI, every pod gets an IP address from the subnet and can be accessed directly. These IP addresses must be planned in advance and unique across your network space. Each node has a configuration parameter for the maximum number of pods it supports. The equivalent number of IP addresses per node are then reserved up front. This approach can lead to IP address exhaustion or the need to rebuild clusters in a larger subnet as your application demands grow, so it's important to plan properly.

Unlike kubenet, traffic to endpoints in the same virtual network isn't NAT'd to the node's primary IP. The source address for traffic inside the virtual network is the pod IP. Traffic that's external to the virtual network still NATs to the node's primary IP.

Nodes use the Azure CNI Kubernetes plugin.

References:

Event-driven scaling in Azure Functions

Network concepts for applications in Azure Kubernetes Service (AKS)

Configure Azure CNI networking in Azure Kubernetes Service (AKS)

• Assign User3 the Contributor role for Sub1.
• Assign Group1 the Virtual Machine Contributor role for MG1.
• Assign Group3 the Contributor role for the Tenant Root Group.

Explanation:

User1 is a member of Group3. Group3 has the Contributor role at the Tenant Root Group assigned. The Contributor role grants full access to manage all resources, but does not allow to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries. User1 can create virtual machines in all subscriptions and all resource groups.

User2 is a member of Group2, which is a member of Group3. Group3 has the Contributor role at the Tenant Root Group assigned. The Contributor role grants full access to manage all resources, but does not allow to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries. User2 cannot grant permissions to other users.

User3 is a member of Group1 and Group2, which both are member of Group3. Group3 has the Contributor role at the Tenant Root Group assigned. The Contributor role grants full access to manage all resources, but does not allow to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries. User3 can create storage accounts in all subscriptions and all resource groups.

Note: RBAC role assignments are transitive for groups which means that if a user is a member of a group and that group is member of another group that has a role assignment, the user will have the permissions in the role assignment.

Reference: Azure built-in roles

Explanation:

We should use Azure Policy to enforce tagging rules and conventions. By creating a policy, we avoid the scenario of resources being deployed to the subscription that don't have the expected tags (e.g. department=Marketing) for the organization. Instead of manually applying tags or searching for resources that aren't compliant, we should create a policy that automatically applies the needed tags during deployment. Tags can also now be applied to existing resources with the new Modify effect and a remediation task.

Reference: Assign policy definitions for tag compliance

• User1 must be able to create user accounts.
• User2 must be able to reset user passwords.

Explanation:

We should assign the User Administrator role for MarketingAU to User1 and the Helpdesk Administrator role for MarketingAU to User2.

• Support SQL queries.
• Support geo-replication.
• Store and access data relationally.

Explanation:

Azure Cosmos DB is a globally distributed database system that allows you to read and write data from the local replicas of your database. Azure Cosmos DB transparently replicates the data to all the regions associated with your Azure Cosmos DB account. Azure Cosmos DB is a globally distributed database service that's designed to provide low latency, elastic scalability of throughput, well-defined semantics for data consistency, and high availability. In short, if your application needs fast response time anywhere in the world, if it's required to be always online, and needs unlimited and elastic scalability of throughput and storage, you should build your application on Azure Cosmos DB.

Azure Cosmos DB for PostgreSQL is a managed service for running PostgreSQL at any scale, with the Citus open source superpower of distributed tables. It stores data either on a single node, or distributed in a multi-node configuration.

Azure Cosmos DB for PostgreSQL supports standard SQL statements such as SELECT, DELETE, and UPDATE.

References:

Distribute your data globally with Azure Cosmos DB

Choose an API in Azure Cosmos DB

Query distributed tables in Azure Cosmos DB for PostgreSQL