Practice Test #2

No. By default, an NSG’s outbound security rules include the built-in rule set: AllowVnetOutbound, AllowInternetOutbound, and DenyAllOutbound. While AllowInternetOutbound permits outbound traffic to the Internet, it is not an explicit “HTTPS allowed” rule; it allows all outbound protocols/ports to Internet (subject to other higher-priority rules). Also, many exam questions interpret “HTTPS traffic is allowed” as requiring an explicit rule for TCP/443. In practice, if you add a higher-priority deny rule or if the destination is not considered “Internet” (e.g., service tags, private endpoints), HTTPS may not be allowed. Therefore, it’s incorrect to state that HTTPS is allowed by default as a specific outbound rule; the default is broader (allow all outbound to Internet) and can be overridden.

No. A VPN Gateway is not strictly required to connect Azure to on-premises. You have multiple connectivity patterns: - Site-to-Site VPN uses an Azure VPN Gateway (required for that option). - ExpressRoute provides private connectivity via an ExpressRoute circuit and an ExpressRoute virtual network gateway (not a VPN gateway). - Point-to-Site VPN also uses a VPN gateway, but it’s for individual clients. Because the statement says “VPN Gateway is required” for any Azure-to-on-premises connectivity, it is false. In AZ-305, you should choose connectivity based on requirements: ExpressRoute for higher reliability/throughput and private peering, VPN for lower cost and quicker setup. Both can meet “connect to on-premises,” so VPN Gateway is not universally required.

Yes. Azure Load Balancer supports both inbound and outbound scenarios. For inbound, it distributes incoming TCP/UDP traffic to backend instances (VMs/VMSS) using load-balancing rules and health probes, and it can provide inbound NAT rules for port forwarding to specific instances. For outbound, Standard Load Balancer supports outbound connectivity via outbound rules (and historically via implicit SNAT behavior), allowing instances without public IPs to initiate connections to the Internet through the load balancer’s frontend. This is a common AZ-305 point: Standard Load Balancer is a Layer 4 service (not HTTP-aware like Application Gateway) and can be used to manage both inbound distribution and controlled outbound SNAT at scale.

Sub-question 2008 does not contain an answerable certification item. The provided options ('Pass'/'Fail') are unrelated to the Azure Backup policy shown in the exhibit and do not correspond to any valid hotspot selection. Because the actual hotspot prompt is missing and the image only shows the backup policy configuration, there is not enough context to determine a correct answer for this sub-question.

Maximum recovery window is determined by the longest retention period among the enabled retention ranges, not by summing daily + weekly + monthly. From the policy: - Daily recovery points retained for 90 days. - Weekly recovery points retained for 26 weeks. - Monthly recovery points retained for 36 months. - Yearly retention is not configured. Because monthly retention is enabled for 36 months, you can recover to a recovery point as old as 36 months (subject to having a monthly recovery point for that period). The 90-day and 26-week settings provide additional restore points for more recent time ranges but do not extend the maximum beyond the longest tier. Why others are wrong: - 90 days and 26 weeks are shorter than 36 months. - 45 months is not configured anywhere; you cannot add 36 months + 26 weeks + 90 days because these retentions overlap and represent different granularity tiers, not cumulative time.

Recovery Point Objective (RPO) is the maximum acceptable data loss measured in time, and for Azure VM backups it is primarily driven by how often backups are taken (the backup schedule frequency). The policy shows: - Frequency: Daily - Time: 6:00 PM (UTC) That means Azure Backup creates one scheduled recovery point per day. Therefore, the minimum (best-case) RPO you can achieve with this policy is 1 day, because in the worst case you could lose up to nearly 24 hours of changes between backups. Why others are wrong: - 1 hour is not achievable with a daily schedule (it would require more frequent backups). - 1 week, 1 month, and 1 year are retention/granularity concepts, not the backup frequency here. Weekly/monthly retention controls how long certain recovery points are kept, not how often they are created. - Instant Restore (3 days) affects restore speed/location, not backup frequency, so it does not reduce RPO below daily.

Correct: A Traffic Manager profile. Azure Traffic Manager provides global DNS-based routing across endpoints (such as two App Service apps in North Europe and West Europe). It continuously probes endpoint health and can direct users to the primary region, failing over automatically if the primary becomes unavailable. This directly satisfies the requirement that users always access North Europe unless that region fails, and it provides regional availability. Why not Azure Application Gateway (B): Application Gateway is a regional Layer 7 load balancer. To cover two regions, you would typically deploy one per region and then still need a global routing mechanism (often Traffic Manager or Front Door) to choose between regions. That adds cost and complexity beyond what is required. Why not Azure Load Balancer (C): Azure Load Balancer is regional Layer 4 and cannot provide cross-region DNS-based failover for App Service endpoints. It’s not the right tool for global/regional failover routing.

Correct: Priority traffic routing. Priority routing in Traffic Manager is specifically intended for active/passive designs. You configure the North Europe endpoint with the highest priority (lowest priority number) and the West Europe endpoint as the next priority. Traffic Manager sends all users to North Europe as long as it is healthy, and only routes to West Europe when North Europe fails health probes. Why not Performance routing (B): Performance routing chooses the endpoint with the lowest network latency for each user, which could send some users to West Europe even when North Europe is healthy—violating the requirement. Why not Weighted routing (D): Weighted routing distributes traffic across endpoints based on weights (active/active), which would also send some traffic to West Europe during normal operations. Why not Cookie-based session affinity (A): That is an Application Gateway feature for sticky sessions, not a Traffic Manager routing method, and it doesn’t address regional failover preference.

Pass is appropriate because the correct design is a common AZ-305 identity + API protection pattern: authorize in Azure AD and enforce at API Management using JWT validation. The requirement explicitly says to use Azure AD-generated claims and minimize configuration/management. That points away from implementing authorization inside each of the 20 APIs (higher effort) and toward centralized enforcement in APIM policies. So the solution is: configure Azure AD permissions (scopes/app roles) for the web apps to call the APIs, and configure APIM to validate JWTs and required claims. This blocks unauthorized requests at the gateway, before they reach the APIs.

Granting permissions for web apps to access web APIs is done in Azure AD (Microsoft Entra ID) via app registrations. You either: - Expose an API (define OAuth2 scopes) on the API app registration and grant the web app delegated/application permissions, or - Define app roles on the API and assign them to the calling web app/service principal. This is the authoritative place where consent and permission grants are managed and where Azure AD will issue tokens containing the relevant claims (e.g., scp for scopes, roles for app roles). Why not APIM? APIM can enforce tokens but it does not define or grant Azure AD permissions; it integrates with Azure AD. Why not “the web APIs”? Implementing permissions directly in each API would increase management effort and would not be the central permission grant mechanism for Azure AD-issued tokens.

Configure JWT validation in Azure API Management. APIM provides the built-in validate-jwt policy to validate: - Token signature (using Azure AD OpenID metadata) - Issuer (iss) - Audience (aud) - Token lifetime - Required claims such as scopes (scp) or roles (roles) This directly satisfies “block unauthorized requests … from reaching the web APIs” because APIM rejects invalid/unauthorized calls at the gateway layer. Why not Azure AD? Azure AD issues tokens and defines permissions, but it doesn’t sit inline to validate every API request; the resource server/gateway must validate the JWT. Why not “the web APIs”? You could validate JWTs in each API, but that increases configuration and ongoing management across 20 APIs, violating the requirement to minimize effort. Centralizing in APIM is the intended design.