Free Microsoft AZ-104 Practice Exam with Questions & Answers | Set: 4

Every Azure AD directory comes with an initial domain name in the form of domainname.onmicrosoft.com.

The initial domain name cannot be changed or deleted, but you can add your corporate domain name to Azure AD as well. For example, your organization probably has other domain names used to do business and users who sign in using your corporate domain name. Adding custom domain names to Azure AD allows you to assign user names in the directory that are familiar to your users, such as ‘alice@contoso.com.’ instead of 'alice@domain name.onmicrosoft.com'.

Scenario:

Network Infrastructure: Each office has a local data center that contains all the servers for that office. Each office has a dedicated connection to the Internet.

Humongous Insurance has a single-domain Active Directory forest named humongousinsurance.com

Planned Azure AD Infrastructure: The on-premises Active Directory domain will be synchronized to Azure AD.

B: You can gradually roll out Seamless SSO to your users. You start by adding the following Azure AD URL to all or selected users' Intranet zone settings by using Group Policy in Active Directory: https://autologon.microsoftazuread-sso.com

E: Seamless SSO works with any method of cloud authentication - Password Hash Synchronization or Pass-through Authentication, and can be enabled via Azure AD Connect.

Every Azure AD directory comes with an initial domain name in the form of domainname.onmicrosoft.com. The initial domain name cannot be changed or deleted, but you can add your corporate domain name to Azure AD as well. For example, your organization probably has other domain names used to do business and users who sign in using your corporate domain name. Adding custom domain names to Azure AD allows you to assign user names in the directory that are familiar to your users, such as ‘alice@contoso.com.’ instead of 'alice@domain name.onmicrosoft.com'.

Scenario:

Network Infrastructure: Each office has a local data center that contains all the servers for that office. Each office has a dedicated connection to the Internet.

Humongous Insurance has a single-domain Active Directory forest named humongousinsurance.com

Planned Azure AD Infrastructure: The on-premises Active Directory domain will be synchronized to Azure AD.

IP address: You should use 10.0.1.3 as the IP address for DC1. This is because DC1 needs to have a static IP address within the subnet range of VNET1, which is 10.0.1.0/241. You cannot use 10.0.2.1 or 192.168.2.1, as they are outside of the subnet range of VNET1. You also cannot obtain an IP address automatically, as this may cause DC1 to lose its IP address and break the DNS resolution for the domain members2.

Name Resolution: You should configure VNET1 to use a custom DNS server that points to the IP address of DC1, which is 10.0.1.33. This is because DC1 is the domain controller and DNS server for contoso.com, and it needs to resolve the AD DS DNS names for the domain members that are in Azure or on-premises. You cannot use the default Azure-provided DNS server, as it does not support AD DS DNS names. You also do not need to create an Azure Private DNS zone or an Azure public DNS zone named contoso.com, as these are not required for AD DS DNS resolution.

Azure DNS supports importing and exporting zone files by using the Azure command-line interface (CLI). Zone file import is not currently supported via Azure PowerShell or the Azure portal.

According to the Microsoft documentation, Azure Bastion is a service that provides more secure and seamless RDP and SSH access to virtual machines without any exposure through public IP addresses. You can provision the service directly in your local or peered virtual network to get support for all the VMs within it.

In your scenario, you have three virtual networks that are peered with each other. This means that they can communicate with each other as if they were in the same virtual network. Therefore, you can deploy one Bastion host in any of the virtual networks and use it to connect to all the virtual machines in the peered virtual networks. You don’t need to deploy a separate Bastion host for each virtual network or each virtual machine.

For more information about how to deploy and use Azure Bastion, see Tutorial: Deploy Bastion using specified settings: Azure portal.

Box 1: Group 1 only

First rule applies

Box 2: Group1 and Group2 only

Both membership rules apply.

Image 1: Azure Container Apps only.image 2: Azure Container Instances, Azure Container Apps, and App Services.

The images you have in your Azure subscription are different types of container images that can run on different Azure services. A container image is a package of software that includes everything needed to run an application, such as code, libraries, dependencies, and configuration files. Container images are portable and consistent across different environments, such as development, testing, and production.

Azure Container Instances is a service that allows you to run containers directly on the Azure cloud, without having to manage any infrastructure or orchestrators. You can use Azure Container Instances to run any container image that is compatible with the Docker image format and follows the Open Container Initiative (OCI) specification. You can also run Windows or Linux containers on Azure Container Instances.

Azure Container Apps is a service that allows you to build and deploy cloud-native applications and microservices using serverless containers. You can use Azure Container Apps to run any container image that is compatible with the Docker image format and follows the Open Container Initiative (OCI) specification. You can also run Windows or Linux containers on Azure Container Apps.

Azure App Service is a service that allows you to build and host web applications, mobile backends, and RESTful APIs using various languages and frameworks. You can use Azure App Service to run custom container images that are compatible with the Docker image format and follow the App Service Docker image contract. You can also run Windows or Linux containers on Azure App Service.

"To secure app deployment from a local computer, Azure App Service supports two types of credentials for local Git deployment and FTP/S deployment. These credentials are not the same as your Azure subscription credentials." https://learn.microsoft.com/en-us/azure/app-service/deploy-configure-credentials?tabs=cli

When you swap deployment slots, Azure swaps the Virtual IP addresses of the source and destination slots, thereby swapping the URLs of the slots. We can easily revert the deployment by swapping back. Deployment slots are live apps with their own host names. App content and configurations elements can be swapped between two deployment slots, including the production slot. Deploying your application to a non-production slot has the following benefits: 1. You can validate app changes in a staging deployment slot before swapping it with the production slot. 2. Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up before being swapped into production. Reference: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots