Microsoft AZ-104 Practice Test 57
Question 560
A private backend Container App is unexpectedly reachable from public clients. What should be examined?
- Inspect external ingress flags and the environment's public network exposure.
- Change the private registry image-pull role and assume the public ingress setting of the running Container App is disabled.
- Check the image tag or immutable digest referenced by the deployed workload.
- Deploy the container group into an eligible delegated VNet subnet under supported integration.
Explanation
Correct Answer
A:Ingress type determines the application's network audience. A private app should not have unintended public routing. This matters here because a private backend Container App is unexpectedly reachable from public clients.
Incorrect Answers
B:Image pull permission concerns registry reads, not external client reachability. Review the app ingress setting and Container Apps environment network.
C:Pushing a new image does not automatically change every running deployment. Tags and digests determine which image revision is requested. This matters here because a private backend Container App is unexpectedly reachable from public clients.
D:ACI VNet integration uses supported subnet configuration to give the group private connectivity. A private registry alone does not connect it to a VNet. This matters here because a private backend Container App is unexpectedly reachable from public clients.
Question 561
A customer portal should accept requests only from corporate public IP ranges. Which setting provides filtering?
- Configure private inbound access or appropriate App Service access restrictions separately.
- Turn on HTTPS Only for the App Service app.
- Configure App Service access restrictions to allow approved source addresses and deny the rest.
- Inspect managed identity selection, secret permission and vault networking for the reference.
Explanation
Correct Answer
C:Access restrictions evaluate inbound request sources at the App Service boundary. TLS certificates protect transport, not source eligibility. This matters here because a customer portal should accept requests only from corporate public IP ranges. Which setting provides filtering.
Incorrect Answers
A:Outbound VNet integration does not inherently make an App Service web endpoint private. Inbound restrictions are a different feature. This matters here because a customer portal should accept requests only from corporate public IP ranges. Which setting provides filtering.
B:HTTPS Only enforces secure transport for inbound web requests. A valid certificate without enforcement does not guarantee every user avoids HTTP. This matters here because a customer portal should accept requests only from corporate public IP ranges. Which setting provides filtering.
D:A correct secret URI is only one prerequisite. Key Vault references require authorized network reachability and identity permissions. This matters here because a customer portal should accept requests only from corporate public IP ranges. Which setting provides filtering.
Question 562
An approved Azure Front Door route is blocked by an App Service IP rule after deployment. What should be evaluated?
- Inspect active autoscale profiles and rules that control the plan's capacity.
- Use App Service application settings with appropriate deployment-slot stickiness.
- Increase the App Service minimum inbound TLS version to the approved level.
- Review access restriction rules for the expected upstream service address or service tag configuration.
Explanation
Correct Answer
D:A reverse proxy changes the observed source path. The app's inbound allow rules must reflect the trusted upstream in a supported manner. This matters here because an approved Azure Front Door route is blocked by an App Service IP rule after deployment.
Incorrect Answers
A:Automatic scaling can override manual counts according to configured profiles. The effective autoscale policy must align with the event plan. This matters here because an approved Azure Front Door route is blocked by an App Service IP rule after deployment.
B:App settings are injected into the runtime environment and can be marked slot-specific. Image baking is unsuitable for secrets. This matters here because an approved Azure Front Door route is blocked by an App Service IP rule after deployment.
C:HTTPS Only requires encrypted transport but does not, by itself, set the minimum accepted TLS protocol version. This matters here because an approved Azure Front Door route is blocked by an App Service IP rule after deployment.
Question 563
A web app must call Azure Key Vault without a password in app settings. Which identity technique fits?
- Enable the App Service managed identity and grant the needed Key Vault data role.
- Increase the App Service minimum inbound TLS version to the approved level.
- Copy the live Key Vault secret into a plaintext App Service setting while leaving the managed identity unused.
- Create an Azure App Service web app using a supported Python runtime.
Explanation
Correct Answer
A:Managed identities supply Entra tokens to supported services without embedded long-lived application secrets. This matters here because a web app must call Azure Key Vault without a password in app settings. Which identity technique fits.
Incorrect Answers
B:HTTPS Only requires encrypted transport but does not, by itself, set the minimum accepted TLS protocol version. This matters here because a web app must call Azure Key Vault without a password in app settings. Which identity technique fits.
C:Embedding the secret as a literal value in an app setting perpetuates static credential handling. A managed identity needs the appropriate secret data-plane authorization to access Key Vault without embedding credentials.
D:App Service manages supported application hosting and scaling features. A VM-hosted web server adds guest patching responsibilities. This matters here because a web app must call Azure Key Vault without a password in app settings. Which identity technique fits.
Question 564
A managed identity can request a token but Key Vault returns Forbidden. What is missing?
- Inspect active autoscale profiles and rules that control the plan's capacity.
- Check the vault's data-plane authorization model and the identity's effective role or access policy.
- Use an App Service Key Vault reference with managed identity authorization.
- Inspect managed identity selection, secret permission and vault networking for the reference.
Explanation
Correct Answer
B:Authentication is separate from Key Vault secret permissions. A valid identity token does not automatically allow reading secrets.
Incorrect Answers
A:Automatic scaling can override manual counts according to configured profiles. The effective autoscale policy must align with the event plan. This matters here because a managed identity can request a token but Key Vault returns Forbidden. What is missing.
C:Key Vault references can resolve secrets into app configuration under supported identity and vault settings, avoiding plaintext storage. This matters here because a managed identity can request a token but Key Vault returns Forbidden. What is missing.
D:A correct secret URI is only one prerequisite. Key Vault references require authorized network reachability and identity permissions. This matters here because a managed identity can request a token but Key Vault returns Forbidden. What is missing.
Question 565
A platform team wants each App Service instance to remain loaded rather than unload during idle periods. Which option can help?
- Add a second deployment slot and leave the active app eligible for idle unloading.
- Enable Always On on a hosting tier that supports the feature.
- Configure App Service Health Check with an accurate application readiness path.
- Schedule nightly App Service backups and assume the idle production workers never unload the app.
Explanation
Correct Answer
B:Always On sends periodic requests to keep the app loaded, reducing cold starts for applicable plans. This matters here because a platform team wants each App Service instance to remain loaded rather than unload during idle periods. Which….
Incorrect Answers
A:Deployment slots separate release versions but do not keep every app worker loaded. Enable Always On on a supported App Service tier when idle unloading is the concern.
C:Health Check probes a configured endpoint and can mark unhealthy worker instances for exclusion in supported plans. This matters here because a platform team wants each App Service instance to remain loaded rather than unload during idle periods. Which….
D:Backup cadence does not send the regular warm-up requests that Always On provides. Enable Always On where supported by the hosting tier.
Question 566
An app frequently cold-starts despite a correct DNS mapping and healthy TLS certificate. Which setting should be checked?
- Enable autoscale alone while leaving Always On disabled for an intermittently used app.
- Review Always On availability and enablement under the current App Service tier.
- Verify the certificate SAN or common-name coverage and hostname-specific TLS binding.
- Verify the custom domain's DNS records and bind the hostname to the App Service app.
Explanation
Correct Answer
B:Endpoint networking does not prevent idle unloads. Always On and the chosen hosting tier affect application readiness after inactivity.
Incorrect Answers
A:Autoscale changes instance counts under load but doesn't by itself stop idle processes from unloading. Check plan support and the Always On setting for persistent warm instances.
C:A certificate must match the requested host. A correct default endpoint certificate does not automatically cover a custom domain. This matters here because an app frequently cold-starts despite a correct DNS mapping and healthy TLS certificate. Which setting should be checked.
D:DNS and App Service hostname mapping work together. A DNS record alone does not authorize the platform to serve the hostname. This matters here because an app frequently cold-starts despite a correct DNS mapping and healthy TLS certificate. Which setting should be checked.
Question 567
A DNS team wants to publish a private application hostname resolvable only by VNets. Which DNS resource is appropriate?
- Use Azure DNS Private Resolver with an outbound endpoint and forwarding rule set.
- Create an Azure Private DNS zone and link the authorized VNets.
- Use supported BGP-propagated gateway routes with appropriate virtual network gateway configuration.
- Configure virtual network peering between the nonoverlapping VNets.
Explanation
Correct Answer
B:Private DNS zones resolve within linked VNets instead of publishing records to the Internet. Links and resolver paths control client reachability.
Incorrect Answers
A:Private Resolver can forward selected domain queries to reachable DNS servers without self-managed DNS VMs. This matters here because a DNS team wants to publish a private application hostname resolvable only by VNets. Which DNS resource is appropriate.
C:Gateway-learned routes can appear in subnet effective routes under supported propagation and topology. A random public IP rule cannot establish private routing. This matters here because a DNS team wants to publish a private application hostname resolvable only by VNets. Which DNS resource is appropriate.
D:VNet peering connects private Azure address spaces without routing through public internet endpoints. NSG and UDR conditions still apply. This matters here because a DNS team wants to publish a private application hostname resolvable only by VNets. Which DNS resource is appropriate.
Question 568
VMs in one VNet resolve a private host but machines in a second VNet cannot. What should be checked?
- Check Private DNS virtual-network links and any resolver forwarding between networks.
- Split the first VNet into more subnets and assume that makes its private DNS names resolvable from a second VNet.
- Check DNS forwarding ruleset links and resolver endpoint reachability for the client VNet.
- Use Azure DNS Private Resolver with an outbound endpoint and forwarding rule set.
Explanation
Correct Answer
A:Private zone records are visible through linked or appropriately forwarded resolution paths. VNet peering alone does not necessarily share zone links. This matters here because vMs in one VNet resolve a private host but machines in a second VNet cannot.
Incorrect Answers
B:Subnet partitioning does not link a Private DNS zone to another network. Inspect zone virtual-network links or resolver forwarding on the clients' DNS path.
C:Ruleset association determines which VNets use the forwarding configuration. Correct rules in an unlinked ruleset cannot affect clients. This matters here because vMs in one VNet resolve a private host but machines in a second VNet cannot.
D:Private Resolver can forward selected domain queries to reachable DNS servers without self-managed DNS VMs. This matters here because vMs in one VNet resolve a private host but machines in a second VNet cannot.
Question 569
A network owner needs to prevent accidental overlap when adding peered network address spaces. Which planning step is essential?
- Associate a Standard SKU static public IP address with the supported endpoint.
- Review peering address-space synchronization and effective route propagation.
- Use global VNet peering with supported nonoverlapping address spaces.
- Compare every existing and proposed VNet CIDR before applying peering or expansion.
Explanation
Correct Answer
D:Unique address ranges prevent ambiguous routes and unsupported peering. Address plans must account for future subnet growth. This matters here because a network owner needs to prevent accidental overlap when adding peered network address spaces. Which planning step….
Incorrect Answers
A:A static Standard public IP can provide an allocated endpoint address under supported attachment and availability constraints. This matters here because a network owner needs to prevent accidental overlap when adding peered network address spaces. Which planning step….
B:Peering connections may need synchronization after address changes. A new address prefix must be represented in the reachable topology. This matters here because a network owner needs to prevent accidental overlap when adding peered network address spaces. Which planning step….
C:Global peering connects VNets in different regions over Microsoft's backbone. Costs and special limitations must be reviewed. This matters here because a network owner needs to prevent accidental overlap when adding peered network address spaces. Which planning step….
Question 570
Two networks each use 192.168.10.0/24 and a new peering plan needs both. What remediation is required?
- Enable peering between both 192.168.10.0/24 VNets without changing either address plan because Azure translates overlaps.
- Split the /24 into two distinct /25 subnet ranges.
- Configure supported hub routing through an NVA or gateway with allow-forwarded-traffic and UDRs as appropriate.
- Renumber one network or use a supported translation architecture outside ordinary VNet peering.
Explanation
Correct Answer
D:Ordinary Azure VNet peering does not resolve overlapping address spaces by itself. Distinct reachable prefixes are needed. This matters here because two networks each use 192.168.10.0/24 and a new peering plan needs both. What remediation is required.
Incorrect Answers
A:Ordinary Azure VNet peering rejects overlapping parent CIDRs and does not provide automatic NAT. Readdress one network or design an explicit supported translation path.
B:Each one-bit prefix increase halves the address block, producing two equal /25 networks. Azure reserves several addresses in every subnet. This matters here because two networks each use 192.168.10.0/24 and a new peering plan needs both. What remediation is required.
C:Spoke-to-hub peering does not automatically create spoke-to-spoke transitive routing. A routing service or topology change is needed. This matters here because two networks each use 192.168.10.0/24 and a new peering plan needs both. What remediation is required.