Examkin

All practice questions

1198 questions

All types1,198Multiple choice617Multiple select502Matching65Ordering14
Question 681Question →

A company has a regional TCP-based application deployed on Azure Virtual Machines in a single region. The virtual machines use Standard SKU public IP addresses. The solution must distribute TCP traffic at the transport layer and support the existing Standard SKU resources without configuration validation errors. Which load balancing service should you recommend?

Show answer & explanation

Answer: Azure Standard Load Balancer

Answer

Azure Standard Load Balancer
Azure Standard Load Balancer operates at Layer 4 (TCP/UDP) and supports backend resources configured with Standard SKU public IP addresses. Since the application requires regional TCP load balancing and the virtual machines have Standard SKU public IPs, the Standard Load Balancer is the correct choice and avoids SKU validation errors.

Step-by-Step Solution

1
Identify the protocol and routing requirements.
The application requires regional load balancing for TCP (Layer 4) traffic without HTTP-specific features.
This rules out HTTP/HTTPS application-layer load balancers like Azure Front Door.
2
Check the SKU requirements of the backend resources.
The backend virtual machines are configured with Standard SKU public IP addresses.
To prevent SKU mismatch validation errors, the load balancer SKU must match the backend public IP resource SKU (both must be Standard).
3
Select the load balancer that matches both layer and SKU constraints.
Azure Standard Load Balancer operates at Layer 4 and is compatible with Standard SKU backend resources.
This satisfies all constraints without validation failures.

Key Concept

Azure Load Balancer SKU matching and protocol constraints
Question 682Question →

An enterprise is designing a multi-region disaster recovery and business continuity solution for a web application deployed in the East US and West US regions. The application requirements include:

1. Global HTTPS traffic must be routed to the closest region with sub-minute failover detection, SSL/TLS termination, and path-based routing (e.g., routing `/api/*` requests to a specialized service).
2. The back-end relational database must support automatic failover to the secondary region without requiring connection string modifications in the application code.
3. Storage data must be replicated to the secondary region, but write operations are strictly restricted to the primary region until a failover occurs.

Which combination of Azure services and configurations should you recommend?

Show answer & explanation

Answer: Azure Front Door for global traffic routing; Azure SQL Database auto-failover groups; and Read-Access Geo-Redundant Storage (RA-GRS) with write operations directed only to the primary endpoint.

Answer

Azure Front Door for global traffic routing; Azure SQL Database auto-failover groups; and Read-Access Geo-Redundant Storage (RA-GRS) with write operations directed only to the primary endpoint.
The correct architecture uses Azure Front Door for global Layer 7 routing (providing SSL termination and path-based routing), Azure SQL Database auto-failover groups (offering unified listener endpoints that prevent connection string updates), and RA-GRS with writes routed strictly to the primary endpoint.

Step-by-Step Solution

1
Evaluate the global routing requirements.
Azure Front Door is selected because it operates at Layer 7 (HTTP/HTTPS) and natively supports Anycast routing, SSL/TLS termination, path-based routing rules, and sub-minute failovers using health probes. Azure Traffic Manager is ruled out since it operates at the DNS level and cannot perform SSL termination or inspect URL paths.
We must satisfy the requirement for global traffic routing, SSL termination, and path-based routing (/api/*).
2
Evaluate the database auto-failover requirements.
Azure SQL Database auto-failover groups are selected because they provide read-write and read-only listener endpoints that remain constant during a failover, eliminating the need to update application connection strings. Manual active geo-replication is ruled out because it lacks a unified listener endpoint.
We must satisfy the requirement to fail over without modifying connection strings in the application code.
3
Evaluate the storage replication and write constraints.
RA-GRS is selected with writes directed to the primary endpoint. RA-GRS provides read-only access to the secondary endpoint while keeping the primary writeable, satisfying the requirement. Attempting an active-active write configuration on RA-GRS is invalid.
We must verify that replication is geo-redundant and that writes are restricted to the primary region.

Key Concept

Designing multi-region architectures using Azure Front Door for Layer 7 global traffic routing and Azure SQL Auto-failover groups for database business continuity.
Question 683Question →

A financial services firm is planning to migrate a core risk-modeling simulation workload to Azure. The application has the following requirements:
- Complete physical isolation at the hardware level for the underlying physical servers to meet strict compliance mandates.
- In-memory data protection during processing using hardware-based enclaves that support Intel Software Guard Extensions (SGX).
- An overall availability service level agreement (SLA) of 99.99% for the virtual machines.
- The workload runs continuously and cannot tolerate unexpected evictions or interruptions.

Which two of the following configurations should you include in the infrastructure design to meet the requirements? (Select TWO).

Select all that apply

Show answer & explanation

Answer: Azure Dedicated Hosts using the DCsv3-Type1 host size; A host group distributed across at least two Availability Zones

Answer

To meet the requirements, the architecture must include Azure Dedicated Hosts using the DCsv3-Type1 host size and a host group distributed across at least two Availability Zones.
The correct design utilizes Azure Dedicated Hosts using the DCsv3-Type1 host size distributed across at least two Availability Zones. The DCsv3-Type1 host size supports DCsv3-series VMs, which provide the required physical isolation and hardware-enclave protection using Intel SGX. Distributing the hosts across at least two zones ensures the design meets the 99.99% virtual machine availability SLA.

Step-by-Step Solution

1
Identify the compute family that supports the security requirements.
The DCsv3-series virtual machines and DCsv3-Type1 Dedicated Hosts are selected.
Intel SGX-based confidential computing enclaves are supported on DCsv3-series VMs, whereas ECasv5 or other series do not support SGX enclaves.
2
Evaluate high availability and SLA constraints.
A Host Group distributed across at least two Availability Zones must be used.
Azure SLA for Dedicated Hosts requires spreading hosts across at least two zones to guarantee 99.99% VM connectivity.
3
Filter out solutions that introduce eviction risk or fail hardware isolation.
Spot VMs and Consumption-based Azure Functions are ruled out.
Spot VMs are prone to evictions and cannot run on Dedicated Hosts. Azure Functions Consumption plan lacks physical hardware isolation and has execution timeouts.

Key Concept

Designing high-availability and confidential compute solutions using Azure Dedicated Hosts and Intel SGX-enabled virtual machines.
Question 684Question →

An organization is designing the hosting architecture for a new multi-tenant financial application. The solution consists of the following components:

* A Web API that processes incoming payment verification requests. The API must scale down to zero instances during idle periods to minimize costs, must scale out within seconds to handle unpredictable spikes of up to 5,0005,000 concurrent requests, and must connect to a database hosted within a secured Azure Virtual Network (VNet).
* A daily ledger reconciliation process that aggregates data from external feeds and updates the database. The reconciliation process takes approximately 45 minutes to execute and must run inside the same VNet.

You need to select the most cost-effective Azure compute hosting options that satisfy these requirements.

Which hosting combination should you recommend?

Show answer & explanation

Answer: Azure Container Apps for the Web API, and an Azure Container Apps Job for the ledger reconciliation process.

Answer

Azure Container Apps for the Web API, and an Azure Container Apps Job for the ledger reconciliation process.
The combination of Azure Container Apps and an Azure Container Apps Job satisfies all constraints. Azure Container Apps can scale to zero when idle to minimize costs, scales out rapidly, and supports VNet integration to access the secure database. Azure Container Apps Jobs are optimized for run-to-completion batch processes, support VNet integration, and allow execution times up to 24 hours, meaning they will not time out during the 45-minute daily reconciliation run.

Step-by-Step Solution

1
Analyze the scaling and network requirements of the Web API component.
The API requires rapid scaling to handle spikes, scaling to zero to minimize idle costs, and Azure Virtual Network (VNet) integration to access the database.
Azure Container Apps supports scaling to zero and native VNet integration, satisfying all Web API criteria.
2
Analyze the execution and network requirements of the ledger reconciliation process.
The reconciliation process is a run-to-completion task requiring 45 minutes of execution time and VNet integration.
This rules out Azure Functions on a Consumption plan due to its 10-minute execution limit.
3
Evaluate the remaining options to identify the most cost-effective serverless hosting combination.
An Azure Container Apps Job runs on demand, supports VNet integration, allows long execution times (up to 24 hours), and does not require pre-warmed running instances.
Azure Container Apps combined with Azure Container Apps Jobs satisfies all requirements with minimal cost and operational overhead.

Key Concept

Selecting serverless and web application hosting plans based on execution limits, virtual network requirements, and cost-effective scaling patterns.
Estimated Time:2m 30s
Question 685Question →

You are designing a regional TCP-based application infrastructure. You deploy a Standard Azure Load Balancer to distribute inbound traffic across a backend pool of Azure Virtual Machines in a single virtual network. However, when you attempt to add the virtual machines to the backend pool, the configuration fails validation. Which of the following is the most likely cause of this validation failure?

Show answer & explanation

Answer: The virtual machines are associated with Basic SKU public IP addresses.

Answer

The virtual machines are associated with Basic SKU public IP addresses.
The correct option is correct because Azure Standard Load Balancer requires all resources in the backend pool to match its SKU tier. If the virtual machines have Basic SKU public IP addresses attached to their network interfaces, the configuration will fail verification due to SKU mismatch constraints.

Step-by-Step Solution

1
Identify the load balancer SKU being deployed.
The scenario specifies a Standard Azure Load Balancer.
Standard Load Balancers have strict SKU matching requirements for backend resources.
2
Check the SKU requirements for virtual machines in the backend pool.
All virtual machine network interfaces (NICs) and their associated public IP addresses must be Standard SKU.
Standard SKU load balancers do not support mixing Basic SKU public IPs within the same backend pool.
3
Determine the cause of the configuration failure.
The virtual machines are using Basic SKU public IP addresses, preventing successful backend pool association.
Upgrading the public IPs to Standard SKU or removing them is required to resolve the validation failure.

Key Concept

Azure Load Balancer SKU boundary and compatibility constraints
Question 686Question →

A university library is designing an automated document archiving system to merge and compress digitized historical manuscripts into PDF/A format.

The system must meet the following requirements:
* Each document merging task is triggered by a message in an Azure Service Bus queue.
* A single archiving task takes between 1212 and 1818 minutes to complete.
* The archiving engine is packaged as a custom Linux-based container image that requires specialized PDF rendering libraries.
* The system must incur zero compute costs when there are no archiving tasks in the queue.
* Infrastructure management and operational overhead must be minimized.

Which Azure compute solution should you recommend?

Show answer & explanation

Answer: Azure Container Apps jobs

Answer

Azure Container Apps jobs
Azure Container Apps jobs are optimized for run-to-completion tasks triggered by events such as queue messages. They support custom containers, can scale down to zero instances (resulting in zero compute cost when idle), support execution durations of up to 2424 hours, and require no cluster management, aligning perfectly with all constraints.

Step-by-Step Solution

1
Analyze the execution duration requirement of 1212 to 1818 minutes.
Azure Functions on a Consumption plan is ruled out because its maximum execution timeout is 1010 minutes.
Selecting a platform with an execution limit lower than the task duration leads to timeout failures.
2
Evaluate the custom container and operational overhead requirements.
Azure Kubernetes Service (AKS) is ruled out because it introduces significant infrastructure management and operational overhead.
The scenario requires minimizing operational overhead, making managed serverless container hosting a better fit than full Kubernetes orchestration.
3
Evaluate the reliability and cost requirements.
Spot Virtual Machines are ruled out because of eviction risks during long-running tasks, and Azure Container Apps jobs is selected because it scales to zero and supports custom containers.
Azure Container Apps jobs natively support scaling to zero cost when idle, accommodate executions up to 2424 hours, run custom containers, and are fully managed.

Key Concept

Selecting serverless hosting options based on execution duration, custom container support, cost efficiency, and operational overhead.
Question 687Question →

An enterprise is designing a hub-and-spoke virtual network topology in Azure. The hub virtual network, `vnet-hub-weur` (10.200.0.0/1610.200.0.0/16), contains a Virtual Network Gateway connected to an on-premises network. A spoke virtual network, `vnet-spoke-prod` (10.201.0.0/1610.201.0.0/16), contains a workload subnet named `snet-app` (10.201.1.0/2410.201.1.0/24). A pair of network virtual appliances (NVAs) is deployed in the hub and sits behind an internal load balancer at 10.200.4.10010.200.4.100.

The Virtual Network Gateway receives BGP route advertisements from on-premises, including a summary route of 172.16.0.0/12172.16.0.0/12 and a specific database subnet prefix of 172.16.50.0/24172.16.50.0/24. To inspect all on-premises bound traffic, you associate a route table named `rt-spoke-app` with the `snet-app` subnet and add a user-defined route (UDR) for 172.16.0.0/12172.16.0.0/12 pointing to the load balancer at 10.200.4.10010.200.4.100. Gateway route propagation is enabled on `rt-spoke-app`.

During testing, you observe that traffic from `snet-app` to the database tier (172.16.50.10172.16.50.10) bypasses the NVAs and goes directly to the Virtual Network Gateway. Which action should you recommend to ensure all on-premises bound traffic is inspected by the NVAs?

Show answer & explanation

Answer: Disable gateway route propagation on the `rt-spoke-app` route table.

Answer

Disable gateway route propagation on the `rt-spoke-app` route table.
Disabling gateway route propagation on the spoke subnet's route table prevents the BGP-learned routes from on-premises from being dynamically injected into the spoke subnet. This removes the specific BGP route for the database tier. Consequently, traffic to the database subnet matches the user-defined route for the summarized prefix, forcing it to route through the network virtual appliance (NVA) first.

Step-by-Step Solution

1
Analyze how BGP routes propagate to the spoke subnet.
Since gateway route propagation is enabled, the BGP routes 172.16.0.0/12172.16.0.0/12 and 172.16.50.0/24172.16.50.0/24 are dynamically added to the subnet's effective route table with the next hop set to Virtual Network Gateway.
This establishes the baseline routing table of the spoke subnet before user overrides.
2
Evaluate the route selection logic for database traffic (172.16.50.10172.16.50.10).
The destination matches both the BGP route (172.16.50.0/24172.16.50.0/24) and the UDR (172.16.0.0/12172.16.0.0/12). In Azure, routes are evaluated using the Longest Prefix Match (LPM) rule. Because a /24 prefix is longer (more specific) than a /12 prefix, the BGP route takes precedence over the UDR, directing traffic directly to the gateway.
This identifies why the current routing configuration fails to meet the inspection requirement.
3
Determine the configuration change needed to force traffic through the NVA.
Disabling gateway route propagation on the spoke's route table removes the propagated BGP routes from its effective route table. Traffic to the on-premises database tier will then fall back to the UDR for 172.16.0.0/12172.16.0.0/12, sending it to the NVA load balancer. The NVAs, located in the hub, still have route propagation enabled and can forward the traffic to the gateway after inspection.
This establishes the correct architectural remediation path.

Key Concept

Azure Virtual Network routing precedence, BGP route propagation, and transit NVA design
Question 688Question →

A meteorological modeling company is designing the Azure compute virtualization infrastructure for two distinct workloads:

* Workload 1: A weather simulation model that runs daily. The model requires Message Passing Interface (MPI) support with sub-millisecond node-to-node latency, high CPU performance, and cannot tolerate interruptions during its four-hour execution window.
* Workload 2: A public-facing web API providing real-time weather alerts that requires a minimum availability SLA of 99.99% and must scale automatically to handle sudden traffic spikes.

Which two virtual machine configurations should you recommend to meet the requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Deploy Workload 1 on HBv3-series virtual machines within a proximity placement group.; Deploy Workload 2 using Virtual Machine Scale Sets in Flexible orchestration mode spread across multiple Availability Zones.

Answer

Deploy Workload 1 on HBv3-series virtual machines within a proximity placement group, and deploy Workload 2 using Virtual Machine Scale Sets in Flexible orchestration mode spread across multiple Availability Zones.
The correct configurations are deploying the weather simulation on HBv3-series virtual machines in a proximity placement group, and deploying the API on Virtual Machine Scale Sets in Flexible orchestration mode across multiple Availability Zones. HBv3-series provides the InfiniBand networking and high compute capacity needed for MPI simulation workloads, and the proximity placement group ensures lowest possible latency by placing VMs physically close. Virtual Machine Scale Sets in Flexible orchestration mode distributed across multiple Availability Zones provide the autoscaling functionality and meet the 99.99% VM SLA requirement.

Step-by-Step Solution

1
Analyze Workload 1 requirements for MPI support, sub-millisecond node-to-node latency, and no tolerance for interruptions.
Identify that HBv3-series virtual machines (HPC-optimized with InfiniBand) are required, and a proximity placement group must be used to keep latency minimal. Spot VMs must be avoided because they can be evicted, which violates the zero-interruption constraint.
Ensures that the compute selection matches the networking and performance requirements of the simulation model.
2
Analyze Workload 2 requirements for a 99.99% availability SLA and autoscaling capability.
Determine that achieving a 99.99% VM SLA in Azure requires distributing virtual machines across multiple Availability Zones in the same region. Virtual Machine Scale Sets with Flexible orchestration mode provide both auto-scaling capabilities and zonal redundancy.
Ensures the high-availability and scale targets are met using Azure best practices.
3
Select the two options that match the identified configurations.
Choose the configurations recommending HBv3-series with proximity placement groups, and Virtual Machine Scale Sets in Flexible orchestration mode across multiple zones.
Provides the complete recommended architecture satisfying all business and technical constraints.

Key Concept

Designing compute virtualization solutions in Azure requires matching VM series capabilities (such as HPC-optimized HBv3-series with InfiniBand for MPI workloads) and architectural patterns (such as multi-zone Virtual Machine Scale Sets in Flexible orchestration mode for high-availability SLAs) to workload constraints.
Question 689Question →

An enterprise is designing the network routing topology for an Azure environment. The topology includes the following components:
- A hub virtual network named `vnet-hub-cus` (10.100.0.0/1610.100.0.0/16) containing an Azure Firewall with the private IP address 10.100.2.410.100.2.4 and an ExpressRoute virtual network gateway.
- A production spoke virtual network named `vnet-prod-spoke` (10.110.0.0/1610.110.0.0/16) with a subnet named `snet-prod-app` (10.110.1.0/2410.110.1.0/24).
- A shared services spoke virtual network named `vnet-shared-spoke` (10.120.0.0/1610.120.0.0/16) with a subnet named `snet-shared-db` (10.120.1.0/2410.120.1.0/24).

The virtual networks `vnet-prod-spoke` and `vnet-shared-spoke` are peered directly with `vnet-hub-cus` but are not peered with each other.

The design must meet the following requirements:
- All traffic between `snet-prod-app` and `snet-shared-db` must be routed through the Azure Firewall for inspection.
- Virtual machines in `snet-prod-app` must be able to communicate with the on-premises network (172.16.0.0/12172.16.0.0/12) via the ExpressRoute gateway.
- Traffic between virtual machines within the same subnet (`snet-prod-app`) must remain local and bypass the Azure Firewall.

Which TWO configurations should you implement to meet these requirements?

Select all that apply

Show answer & explanation

Answer: In the route table associated with the `snet-prod-app` subnet, add a route for 10.120.0.0/1610.120.0.0/16 with the next hop set to the Virtual Appliance IP address 10.100.2.410.100.2.4.; Configure the virtual network peering between `vnet-hub-cus` and `vnet-prod-spoke` to enable gateway transit on the hub virtual network and use the remote virtual network's gateway on the spoke virtual network.

Answer

To meet the requirements, you must add a User Defined Route (UDR) for the shared services spoke network prefix (10.120.0.0/1610.120.0.0/16) pointing to the Azure Firewall's private IP (10.100.2.410.100.2.4) as the next hop in the subnet's route table, and configure the peering between the hub and production spoke to enable gateway transit on the hub virtual network while utilizing the remote gateway on the spoke virtual network.
The correct configurations involve implementing a specific User Defined Route (UDR) for the destination spoke virtual network (10.120.0.0/1610.120.0.0/16) pointing to the Azure Firewall (10.100.2.410.100.2.4) as a Virtual Appliance. This redirects spoke-to-spoke traffic through the firewall. Additionally, configuring the virtual network peering to use the hub's gateway for transit allows BGP route propagation for on-premises routes to reach the spoke subnet, securing transit connectivity to the on-premises network.

Step-by-Step Solution

1
Analyze virtual network peering requirements for on-premises connectivity.
Determine that spoke virtual networks must utilize the ExpressRoute gateway in the hub virtual network by enabling gateway transit on the hub side of the peering and enabling remote gateway usage on the spoke side of the peering.
This allows the spoke virtual network to dynamically learn routes advertised by the gateway via BGP and send on-premises traffic (172.16.0.0/12172.16.0.0/12) through the hub gateway.
2
Configure routing for spoke-to-spoke traffic while preserving local routing behavior.
Determine that a route for the remote spoke's address prefix (10.120.0.0/1610.120.0.0/16) must be added to the route table associated with the production subnet pointing to the Azure Firewall (10.100.2.410.100.2.4) as a Virtual Appliance next hop.
Because the local VNet route (10.110.0.0/1610.110.0.0/16) is more specific than the UDR or is managed by the default local VNet system route, local traffic remains inside the spoke VNet and bypasses the firewall, while traffic to the other spoke is successfully redirected to the firewall.

Key Concept

Azure Virtual Network peering gateway transit and User-Defined Routes (UDR) precedence over default system routes.
Estimated Time:3m 0s
Question 690Question →

An organization is planning to migrate their on-premises VMware vSphere virtual machines (VMs) to Azure using Azure Migrate. Before scheduling the migration, they want to analyze the network connections and dependencies between their servers to ensure no critical connections are broken. Which two methods can they use to perform dependency analysis in Azure Migrate? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Perform agentless dependency analysis by using the Azure Migrate appliance to collect TCP connection data.; Perform agent-based dependency analysis by installing the Dependency agent and the Log Analytics agent on each VM.

Answer

The two valid methods are agentless dependency analysis using the Azure Migrate appliance and agent-based dependency analysis using agents installed on each VM.
Azure Migrate provides two primary methods for dependency mapping: agentless analysis, which requires no software installation on the VMs, and agent-based analysis, which uses the Log Analytics agent and Dependency agent to gather granular process-level connection data.

Step-by-Step Solution

1
Determine the migration discovery and assessment options in Azure Migrate.
Identify that Azure Migrate provides two distinct modes for assessing virtual machine network dependencies: agentless and agent-based.
Understanding the options allows you to align the assessment strategy with the organization's security and deployment guidelines.
2
Evaluate the agentless option.
The agentless method relies on the Azure Migrate appliance to query vCenter Server APIs and collect network metadata.
This configuration avoids the administrative overhead of managing agent installations on target VMs.
3
Evaluate the agent-based option.
The agent-based method requires installing the Log Analytics agent and the Dependency agent on target systems.
This is chosen when deeper process-level detail is needed or when hypervisor-level metadata collection is restricted.

Key Concept

Azure Migrate dependency analysis methodologies
Question 691Question →

An organization is designing a disaster recovery (DR) solution from the North Europe region to the West Europe region for an application hosted on an Azure Virtual Machine (VM1). The business requirements specify a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 2 hours. VM1 runs a high-throughput PostgreSQL database and has the following disk configuration:

- OS Disk: 128 GB Premium SSD with a peak write churn of 2 MB/s
- Data Disk: 1 TB Premium SSD with a peak write churn of 28 MB/s
- Log Disk: 256 GB Premium SSD with a peak write churn of 32 MB/s

The total peak write churn for VM1 is 62 MB/s. Which disaster recovery design should you recommend to meet the requirements?

Show answer & explanation

Answer: Replicate VM1 using Azure Site Recovery, excluding the Data Disk and Log Disk from replication, and implement PostgreSQL native streaming replication to the target region for database data.

Answer

Replicate VM1 using Azure Site Recovery, excluding the Data Disk and Log Disk from replication, and implement PostgreSQL native streaming replication to the target region for database data.
The correct design uses Azure Site Recovery to replicate the virtual machine's OS disk while excluding the high-churn database disks (Data Disk and Log Disk). To protect the database workload without exceeding replication thresholds, native database-level replication (PostgreSQL streaming replication) is implemented. This combination respects the per-disk limits of ASR (which caps Premium SSD write churn at 30 MB/s even with High Churn support) while ensuring database replication remains within the 15-minute RPO constraint.

Step-by-Step Solution

1
Analyze the write churn limits for standard Azure Site Recovery (ASR) replication.
Standard ASR limits write churn to 15 MB/s per Premium SSD disk and 54 MB/s per VM. The VM's Data Disk (28 MB/s), Log Disk (32 MB/s), and total VM churn (62 MB/s) all exceed these thresholds.
To determine if standard ASR replication is a viable option.
2
Analyze the write churn limits for ASR High Churn support.
ASR High Churn support allows up to 30 MB/s per Premium SSD disk and 100 MB/s per VM. While the total VM churn (62 MB/s) and Data Disk churn (28 MB/s) are within limits, the Log Disk peak write churn (32 MB/s) still exceeds the 30 MB/s per-disk limit.
To evaluate if the ASR High Churn feature can accommodate the workload.
3
Select a hybrid replication strategy combining ASR and native database replication.
Exclude the high-churn database disks (Data Disk and Log Disk) from ASR replication to avoid replication failures. Replicate the OS disk using ASR to handle VM configuration recovery, and set up native PostgreSQL streaming replication to replicate the database transactions with a low RPO/RTO.
To design a supported solution that meets the RPO and RTO requirements.

Key Concept

Azure Site Recovery (ASR) write churn limits and disk exclusion strategy
Question 692Question →

A health-tech company is designing a disaster recovery and traffic routing solution for a global patient portal hosted in both the East US 2 and UK South regions. The design must meet the following requirements:
- Terminate SSL sessions at the global entry point.
- Inspect traffic using a Web Application Firewall (WAF).
- Route requests dynamically based on the URL path, directing `/clinical/*` to one set of backend services and `/billing/*` to another.
- Ensure failover to the secondary region occurs in under 30 seconds during an outage, without relying on client-side DNS caching updates.

Which Azure service or feature should you recommend to manage the ingress traffic routing?

Show answer & explanation

Answer: Azure Front Door

Answer

Azure Front Door
The correct answer is Azure Front Door. Azure Front Door is a global Layer 7 load balancer that uses Anycast-based routing. It natively supports SSL offloading, WAF policy integration, and path-based routing. Because it splits TCP sessions close to users and uses Anycast, failover to a healthy region is extremely fast (under 30 seconds) and does not rely on client DNS cache expiration to route traffic away from an unhealthy region.

Step-by-Step Solution

1
Analyze the Layer 7 requirements of the portal.
The solution requires path-based routing, SSL termination, and WAF inspection. These are Application Layer (Layer 7) requirements.
This rules out DNS-based or Layer 4 network solutions that cannot inspect HTTP paths or perform SSL termination.
2
Analyze the failover time and DNS caching constraints.
Failover must happen in under 30 seconds without relying on client-side DNS updates. This indicates that an Anycast-based routing mechanism is needed instead of DNS-based routing.
DNS-based failover is dependent on client-side DNS caching and TTL, which often delays redirection beyond 30 seconds.
3
Evaluate SKU compatibility and scope of remaining options.
Mixing Standard Load Balancer with Basic SKU public IPs is invalid and will fail validation, and database failover groups are not web traffic routing services.
This confirms that Azure Front Door is the only valid, supported service that meets all architectural criteria.

Key Concept

Design Traffic Routing and Failover Strategies
Question 693Question →

An enterprise is designing the network security for a two-tier application in Azure. The design includes:

* A virtual network named VNet1 containing two subnets: WebSubnet and DataSubnet.
* WebSubnet hosts web server virtual machines (VMs) that do not have public IP addresses.
* DataSubnet hosts a Private Endpoint for an Azure SQL Database named sql-db1.
* WebSubnet is associated with a Network Security Group (NSG) named NSG-Web.
* DataSubnet is associated with an NSG named NSG-Data.

The design must meet the following requirements:
* The web servers must connect to sql-db1 securely over its private IP address.
* All outbound traffic from WebSubnet to the internet must be blocked.
* Outbound traffic from WebSubnet must be restricted so that the web servers can only communicate with the Private Endpoint of sql-db1 and no other resources in VNet1.
* The design must minimize administrative effort by avoiding the use of individual, hardcoded IP addresses in NSG rules.

Which two configurations should you include in the design? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Associate the network interface of the Private Endpoint for sql-db1 with an Application Security Group (ASG), and reference this ASG as the destination in an outbound security rule for NSG-Web.; Enable network policies for private endpoints on DataSubnet.

Answer

The correct configurations are to associate the Private Endpoint's network interface with an Application Security Group (ASG) and reference it in the outbound NSG rule, and to enable network policies for private endpoints on the subnet hosting the Private Endpoint.
To secure traffic to a Private Endpoint using Network Security Groups (NSGs) or Application Security Groups (ASGs), you must first enable network policies for private endpoints on the subnet where the Private Endpoint is deployed (DataSubnet). Once enabled, you can associate the Private Endpoint's network interface with an ASG and reference that ASG in the outbound security rules of the source subnet's NSG (NSG-Web). This dynamically permits traffic to the Private Endpoint without needing to hardcode private IP addresses, minimizing administrative overhead.

Step-by-Step Solution

1
Enable network policies for private endpoints on DataSubnet.
Network security rules (including NSG and ASG policies) are now enforced on traffic flowing to the Private Endpoint in DataSubnet.
By default, Azure does not enforce NSG or ASG policies on Private Endpoints. Enabling this setting on the subnet is required to apply security rules to the Private Endpoint.
2
Associate the Private Endpoint's network interface with an ASG and reference it in the NSG-Web outbound rule.
Outbound traffic from WebSubnet is successfully restricted to only the Private Endpoint without using hardcoded IP addresses.
This minimizes administrative effort compared to manually configuring individual IP addresses, while still providing the required isolation.
3
Analyze and eliminate incorrect options.
The service tag and service endpoint options are ruled out because they do not apply to the private IP path of the Private Endpoint.
The Sql service tag only represents public IP ranges, and Service Endpoints route traffic to public endpoints. The VirtualNetwork service tag is too broad as it allows traffic to all VNet resources.

Key Concept

Enforcing network security policies on Private Endpoints using subnet settings and Application Security Groups.
Question 694Question →

An enterprise is designing a hub-and-spoke network topology in Azure to host a secure multi-tier application. The architecture consists of:

* A hub virtual network named `vnet-hub-core` (10.100.0.0/1610.100.0.0/16) that hosts a central firewall Network Virtual Appliance (NVA) at IP address 10.100.2.410.100.2.4.
* A spoke virtual network named `vnet-prod-spoke` (10.150.0.0/1610.150.0.0/16) that contains two subnets: `snet-web` (10.150.1.0/2410.150.1.0/24) and `snet-db` (10.150.2.0/2410.150.2.0/24).
* Virtual network peering established between `vnet-hub-core` and `vnet-prod-spoke` with gateway transit and remote gateway options enabled.

A route table named `rt-web-tier` is associated with `snet-web` and contains a user-defined route (UDR) for 10.150.2.0/2410.150.2.0/24 with a next hop pointing to the NVA (10.100.2.410.100.2.4) to inspect all database-bound traffic. However, when web servers in `snet-web` attempt to establish database connections to VMs in `snet-db`, the connections time out. The database servers are verified as active, and Network Security Groups (NSGs) allow the traffic.

Which of the following routing configurations is the most appropriate solution to resolve the connectivity issue?

Show answer & explanation

Answer: Create a new route table with a UDR for 10.150.1.0/2410.150.1.0/24 pointing to the NVA (10.100.2.410.100.2.4) as the next hop, and associate it with `snet-db`.

Answer

Create a new route table with a UDR for 10.150.1.0/2410.150.1.0/24 pointing to the NVA (10.100.2.410.100.2.4) as the next hop, and associate it with `snet-db`.
The correct option is to create a new route table with a UDR for the web subnet's IP range pointing to the NVA, and associate it with the database subnet. Because the database subnet does not have a route table, it defaults to the system local route for the virtual network, bypassing the NVA on the return path. This causes asymmetric routing, which leads the stateful NVA to drop the traffic. Enforcing the return path through the NVA resolves the timeout issue.

Step-by-Step Solution

1
Analyze the outbound path from the web tier to the database tier.
Traffic from `snet-web` (10.150.1.0/2410.150.1.0/24) to `snet-db` (10.150.2.0/2410.150.2.0/24) matches the UDR for 10.150.2.0/2410.150.2.0/24 in `rt-web-tier` and is successfully forwarded to the NVA (10.100.2.410.100.2.4).
Verify that the outbound packets are correctly routed to the security appliance.
2
Analyze the return path from the database tier back to the web tier.
Since `snet-db` has no associated route table, return traffic destined for `snet-web` (10.150.1.0/2410.150.1.0/24) uses the default system route for the virtual network (10.150.0.0/1610.150.0.0/16 -> Local) and bypasses the NVA.
Identify the cause of connection timeouts, which is asymmetric routing. Stateful firewalls drop connection tracking packets (like TCP SYN-ACK) if they do not observe the initial handshake request.
3
Select a solution that ensures symmetric traffic flow through the firewall.
Create a route table containing a UDR for 10.150.1.0/2410.150.1.0/24 pointing to the NVA and associate it with `snet-db`. This forces the return traffic to flow through the NVA, completing the symmetric path.
Ensure that the stateful firewall tracks both directions of the connection, enabling communication to succeed.

Key Concept

Stateful network virtual appliances (NVAs) require symmetric routing to monitor and allow TCP handshakes. When routing traffic between subnets through an NVA, User-Defined Routes must be applied to both the source and destination subnets to prevent return packets from bypassing the NVA via the default local system route.
Estimated Time:1m 30s
Question 695Question →

Your company is assessing the migration of an on-premises Microsoft SQL Server database to Azure. The database relies on cross-database queries and SQL Server Agent jobs to perform nightly transactional processing. Which Azure SQL deployment option should you select to support these features with minimal modification to the database or application code?

Show answer & explanation

Answer: Azure SQL Managed Instance

Answer

Azure SQL Managed Instance
Azure SQL Managed Instance is designed for migrating on-premises SQL Server instances to Azure with minimal migration effort. It provides near-complete compatibility with the on-premises SQL Server database engine, including support for instance-level features such as SQL Server Agent, SQL Server Database Mail, Service Broker, and cross-database queries.

Step-by-Step Solution

1
Identify the key technical requirements from the assessment phase.
The requirements are native support for SQL Server Agent jobs and cross-database queries.
These are specific features used by the database that must be supported in the target environment.
2
Evaluate the capabilities of Azure SQL Database vs. Azure SQL Managed Instance.
Azure SQL Database (single databases, elastic pools, serverless) does not natively support SQL Server Agent or cross-database queries. Azure SQL Managed Instance supports these instance-level features.
This determines which deployment option minimizes code modification.
3
Select the option that meets the requirements with minimal modification.
Azure SQL Managed Instance is selected.
It offers near-complete compatibility with SQL Server, directly supporting the identified features.

Key Concept

Selecting the appropriate Azure SQL deployment option during migration assessment based on database dependencies and instance-level features.
Question 696Question →

An enterprise is designing a hub-and-spoke virtual network topology in Azure to support a multi-tier application. The topology consists of the following components:
- A hub virtual network named `vnet-hub-eus` (10.100.0.0/1610.100.0.0/16) that contains an Azure Firewall at IP address `10.100.1.4` and a Virtual Network Gateway connected to an on-premises environment via ExpressRoute.
- A spoke virtual network named `vnet-prod-spoke` (10.101.0.0/1610.101.0.0/16) containing a subnet named `snet-web` (10.101.1.0/2410.101.1.0/24).
- A virtual network peering connection between `vnet-hub-eus` and `vnet-prod-spoke` with gateway transit configured to allow the spoke to use the hub's gateway.

The on-premises network advertises specific subnets including `192.168.10.0/24` and `192.168.20.0/24` via BGP. You associate a new route table named `rt-prod-web` with the `snet-web` subnet.

You need to design a routing solution that meets the following requirements:
- All traffic from `snet-web` to the internet and to the on-premises subnets must be routed through the Azure Firewall.
- All traffic within the `vnet-prod-spoke` virtual network must route directly between resources and must not go through the Azure Firewall.
- The solution must minimize administrative overhead and avoid configuring individual routes for each on-premises subnet.

Which two actions should you perform to meet the requirements?

Select all that apply

Show answer & explanation

Answer: Disable virtual network gateway route propagation on the rt-prod-web route table.; Add a route for 0.0.0.0/0 with the next hop set to Virtual Appliance and the next hop address 10.100.1.4 to the rt-prod-web route table.

Answer

To meet the requirements, you must disable virtual network gateway route propagation on the route table associated with the spoke subnet, and add a default route (0.0.0.0/0) pointing to the Azure Firewall IP address (10.100.1.4).
Disabling virtual network gateway route propagation on the spoke subnet's route table prevents the specific on-premises routes advertised via BGP from being dynamically injected into the subnet's routing table. Consequently, all traffic destined for the on-premises networks and the internet will match the default route (0.0.0.0/0) pointing to the Azure Firewall. Since the local virtual network prefix (10.101.0.0/16) has a more specific system route, local traffic bypasses the default route and remains routed directly within the virtual network.

Step-by-Step Solution

1
Identify BGP route propagation impact
By default, BGP-propagated routes from the Virtual Network Gateway (like 192.168.10.0/24 and 192.168.20.0/24) are added to the subnet's routing table. Because these prefixes are more specific than a default route (0.0.0.0/0), traffic destined for these ranges will bypass the Azure Firewall.
Azure routing prefers the longest prefix match (LPM).
2
Disable route propagation on spoke subnet
Disabling virtual network gateway route propagation on the route table associated with the spoke subnet prevents these specific BGP routes from being populated in the spoke subnet's routing table.
This removes the more specific BGP paths from the local routing table, allowing wider UDRs to intercept the traffic.
3
Add a default route to Azure Firewall
Define a default route (0.0.0.0/0) pointing to the Azure Firewall (10.100.1.4). Since the BGP routes are no longer present in the subnet's routing table, all traffic destined for the internet and the on-premises subnets will match the default route and be forwarded to the Azure Firewall.
The firewall subnet still has gateway route propagation enabled, so it will successfully forward the inspected traffic to the virtual network gateway.
4
Verify local VNet routing
The local VNet route (10.101.0.0/16 with next hop 'Virtual Network') remains in the routing table and takes precedence over 0.0.0.0/0 because it is more specific.
This ensures intra-spoke traffic does not route through the firewall, fulfilling the second requirement.

Key Concept

Azure Virtual Network Routing Precedence and Gateway Route Propagation
Estimated Time:2m 30s
Question 697Question →

A financial services firm is modernizing its payment processing platform by migrating key workloads to Azure. The architecture team is designing a load balancing and traffic delivery solution that must meet the following requirements:

* External client transactions over HTTPS must be routed globally to regional endpoints using path-based rules (e.g., routing `/process` and `/refund` requests to dedicated backend services) with SSL/TLS termination performed at the edge.
* The internal backend database tier, which communicates over TCP port 14331433, must be load-balanced regionally across virtual machines in a virtual network.
* The database virtual machines currently have legacy Basic SKU Public IP addresses assigned for administrative access.
* The solution must support high-availability configurations for all load balancers without validation or deployment failures.

Which architecture configuration should you recommend to meet these requirements?

Show answer & explanation

Answer: Deploy Azure Front Door to manage global HTTP/S routing and SSL/TLS termination. Upgrade the public IP addresses of the database virtual machines to Standard SKU, and deploy a Standard Load Balancer to load balance the regional TCP port 1433 traffic.

Answer

Deploy Azure Front Door to manage global HTTP/S routing and SSL/TLS termination. Upgrade the public IP addresses of the database virtual machines to Standard SKU, and deploy a Standard Load Balancer to load balance the regional TCP port 1433 traffic.
The correct architecture combines Azure Front Door for global HTTP/S delivery (providing edge SSL/TLS termination and path-based routing) with a Standard Azure Load Balancer to distribute the TCP port 14331433 database traffic within the region. Because Standard Load Balancers require all associated network interfaces and public IP addresses to use the Standard SKU, the legacy Basic SKU public IP addresses on the database virtual machines must be upgraded to Standard SKU to avoid validation failures.

Step-by-Step Solution

1
Analyze global HTTP/S routing requirements.
Identify that Azure Front Door is required for global routing, SSL/TLS termination, and path-based URL matching.
Azure Front Door is a global Layer 7 load balancer designed specifically for HTTP/S web traffic, whereas Traffic Manager only operates at the DNS level (Layer 4) and Application Gateway is regional.
2
Analyze regional database tier load balancing requirements.
Select Azure Load Balancer (Standard SKU) to handle the database traffic on TCP port 14331433.
Azure Load Balancer is a regional Layer 4 load balancer that handles TCP/UDP protocols, making it suitable for SQL Server database traffic.
3
Evaluate VM Public IP SKU compatibility with the selected Load Balancer.
Determine that the database virtual machines' public IP addresses must be upgraded from Basic SKU to Standard SKU.
Standard Load Balancers require all backend resources to use Standard SKU IP configurations. Mixing Basic SKU Public IPs with a Standard Load Balancer will cause a validation error.

Key Concept

Designing a multi-tier load balancing architecture using Azure Front Door and Standard Load Balancer while adhering to SKU alignment rules.
Question 698Question →

An organization is designing a secure hybrid network environment in Azure. A subnet named Subnet-App in VNet1 hosts virtual machines that must connect to the following resources:
- An Azure Key Vault named vault1 via a Private Endpoint deployed in Subnet-PE (IP range 10.0.2.0/24) in VNet1.
- An Azure Storage account named storage1 via a Private Endpoint deployed in Subnet-PE.
- Microsoft Entra ID for authentication.
- A public partner API (api.partner.com).

The design must satisfy the following requirements:
- Minimize administrative effort when Azure public IP addresses change.
- Route all public internet traffic (including api.partner.com) through an Azure Firewall in a peered hub virtual network.
- Restrict outbound traffic from Subnet-App using a Network Security Group (NSG) to block all outbound traffic by default, except for the minimum necessary traffic required to meet the connectivity requirements.

Which configuration should you recommend for the route table and NSG outbound rules on Subnet-App?

Show answer & explanation

Answer: Associate a route table with a route of 0.0.0.0/0 pointing to the Azure Firewall private IP. Configure NSG rules that allow outbound traffic to 10.0.2.0/24 on port 443, allow outbound traffic to the AzureActiveDirectory service tag on port 443, allow outbound traffic to the Internet service tag on port 443, and deny all other outbound traffic.

Answer

Associate a route table with a route of 0.0.0.0/0 pointing to the Azure Firewall private IP. Configure NSG rules that allow outbound traffic to 10.0.2.0/24 on port 443, allow outbound traffic to the AzureActiveDirectory service tag on port 443, allow outbound traffic to the Internet service tag on port 443, and deny all other outbound traffic.
The correct configuration routes all outbound internet-bound traffic (0.0.0.0/0) to the Azure Firewall. To allow the traffic to leave the subnet and reach the firewall, the NSG must allow outbound traffic to the Internet service tag, as the packet's destination IP is the public IP of the partner API. The NSG must also explicitly allow traffic to the private IP range of the Private Endpoint subnet (10.0.2.0/24) to permit secure access to Key Vault and Storage, while using the AzureActiveDirectory service tag to allow token acquisition with minimal administrative effort.

Step-by-Step Solution

1
Determine how to route public internet traffic through the Azure Firewall.
Create a route table associated with Subnet-App with a user-defined route (UDR) of 0.0.0.0/0 pointing to the private IP of the Azure Firewall as the next hop.
This forces all traffic destined for the public internet to go through the firewall for inspection and filtering.
2
Determine the destination addresses for Private Endpoint traffic in the NSG rules.
Use the private subnet range (10.0.2.0/24) where the Private Endpoints are deployed as the destination in the NSG rule.
Private Endpoints use private IP addresses from the virtual network. Service tags like AzureKeyVault and Storage represent public IP ranges and do not match private VNet IPs.
3
Determine how to permit traffic to Microsoft Entra ID while minimizing administrative effort.
Use the built-in AzureActiveDirectory service tag in the NSG rule.
Service tags automatically manage and update the IP ranges associated with Azure services, removing the need for manual IP maintenance.
4
Determine the NSG rule required for the public partner API traffic when routed through Azure Firewall.
Configure an NSG rule allowing outbound traffic to the Internet service tag (or the specific API endpoint IP if static).
Because NSGs evaluate the packet's final destination IP (the public IP of api.partner.com) rather than the next hop IP (the private IP of the firewall), an outbound deny rule for the Internet service tag would drop the packets before they reach the Azure Firewall.

Key Concept

NSG rules evaluate final destination IPs, not next hop IPs, meaning internet-bound traffic routed through a firewall must still be allowed to the 'Internet' destination in the NSG. Additionally, Private Endpoints use private IPs, so public service tags do not apply to them.
Estimated Time:3m 0s
Question 699Question →

You are designing the compute infrastructure for a manufacturing telemetry processing service. The service will run on Azure Virtual Machines.

The requirements are as follows:
- The virtual machines must achieve a cumulative uptime Service Level Agreement (SLA) of 99.99%99.99\%.
- The virtual machines must be protected against localized datacenter failures (such as power or cooling outages).
- Network latency between the virtual machines must be minimized to support real-time stream aggregation.

Which two design actions should you include in the compute architecture? (Select two.)

Select all that apply

Show answer & explanation

Answer: Deploy the virtual machines across at least two Availability Zones in the Azure region.; Associate the virtual machines with a Proximity Placement Group.

Answer

Deploy the virtual machines across at least two Availability Zones in the Azure region and associate them with a Proximity Placement Group.
To satisfy the 99.99%99.99\% uptime SLA and zone-level fault tolerance, VMs must be distributed across two or more Availability Zones in the region. To satisfy the low-latency stream aggregation requirement, the VMs should be placed within a Proximity Placement Group, which physically groups resources together in the Azure infrastructure.

Step-by-Step Solution

1
Analyze the SLA and high availability requirement.
To achieve a 99.99%99.99\% uptime SLA for Azure Virtual Machines, the instances must be deployed across at least two Availability Zones in the same region.
Deploying instances across zones protects the application from zone-wide physical failures (like power, cooling, or network events).
2
Analyze the network latency requirement.
Use a Proximity Placement Group (PPG) to group the virtual machines.
A Proximity Placement Group ensures that the VMs are physically colocated within the datacenters to minimize network latency.

Key Concept

Combining Availability Zones for 99.99%99.99\% uptime SLA with Proximity Placement Groups for low latency
Question 700Question →

An enterprise is designing a hybrid network architecture to connect an on-premises datacenter to an Azure virtual network named `VNet1` using an ExpressRoute connection. A subnet in `VNet1` named `Subnet1` hosts virtual machines that must access an Azure SQL Database.

The design must meet the following requirements:
- The Azure SQL Database must not expose a public endpoint and must be accessible only via a private IP address within `VNet1`.
- On-premises applications must be able to resolve the database's fully qualified domain name (FQDN) to its private IP address.
- Outbound traffic from `Subnet1` to the database must be restricted at the network layer using Network Security Groups (NSGs).
- Administrative effort for managing DNS routing and network security rules must be minimized.

Which design should you recommend?

Show answer & explanation

Answer: Deploy a Private Endpoint for the Azure SQL Database in a dedicated subnet. Enable private endpoint network policies on the subnet. Configure an Azure DNS Private Resolver with an inbound endpoint in VNet1, and link a private DNS zone named privatelink.database.windows.net to VNet1. Configure the on-premises DNS servers to forward queries for database.windows.net to the inbound endpoint IP.

Answer

Deploy a Private Endpoint for the Azure SQL Database in a dedicated subnet, enable private endpoint network policies, configure an Azure DNS Private Resolver with an inbound endpoint, link the private DNS zone, and configure on-premises DNS servers to forward queries to the inbound endpoint IP.
The correct option addresses the requirements by using a Private Endpoint to ensure the Azure SQL Database is not publicly exposed. It enables network policies on the subnet so that NSG rules can successfully apply to the Private Endpoint. Finally, it uses an Azure DNS Private Resolver with an inbound endpoint, allowing on-premises clients to resolve the database's private IP address using standard DNS forwarders with minimal administrative effort.

Step-by-Step Solution

1
Address the private access requirement
Using an Azure Private Endpoint assigns a private IP address from the virtual network to the Azure SQL Database and allows disabling its public endpoint, fulfilling the primary security requirement.
Service Endpoints still use the public IP of the service and do not allow complete removal of the public endpoint.
2
Implement secure filtering on the Private Endpoint
Enable private endpoint network policies on the subnet hosting the Private Endpoint, which allows Network Security Groups (NSGs) to evaluate and filter traffic destined for the Private Endpoint.
By default, network policies are disabled for private endpoints, meaning NSGs do not filter traffic flowing to them.
3
Configure hybrid DNS resolution with minimal administrative overhead
Link the private DNS zone `privatelink.database.windows.net` to `VNet1` and deploy an Azure DNS Private Resolver with an inbound endpoint. Configure on-premises DNS to conditionally forward queries to the inbound endpoint's IP address.
Azure default DNS (168.63.129.16168.63.129.16) is not routable from on-premises, and manually managing static A records increases administrative overhead.

Key Concept

Azure Private Endpoint Security and Hybrid DNS Integration
PreviousPage 35 / 60Next
All practice questions — Microsoft Azure Solutions Architect (AZ-305) | Examkin