Practice Test #1

Azure Advisor focuses on best-practice recommendations across cost, security, reliability, operational excellence, and performance. It does not provide an authoritative audit trail of ARM deployments or a complete list of new deployments. Advisor may highlight configuration issues resulting from deployments, but it is not designed for compliance-style deployment reporting.

Azure Analysis Services is a PaaS analytics service for hosting tabular semantic models (similar to SSAS Tabular) used by BI tools like Power BI. It does not ingest or track Azure subscription Activity Log events by itself. You could theoretically model data after exporting logs elsewhere, but it is not the correct native service to generate deployment reports.

Azure Monitor action groups define notification and automation endpoints (email, SMS, webhook, Logic Apps, etc.) used by alert rules. They do not collect, store, or enumerate ARM deployment events. Action groups could be used after you create an alert on Activity Log/Log Analytics, but they are not the data source for a monthly deployment report.

This option is incorrect because the proposed solution does meet the stated goal. IP flow verify is one of the core Azure Network Watcher diagnostics for checking whether traffic is permitted or blocked based on effective NSG rules. Although it does not perform full packet inspection or trace every hop across ExpressRoute, the question only asks to identify whether packets are being allowed or denied to the virtual machines. For that purpose, IP flow verify is the appropriate and sufficient tool.

Azure SQL Database active geo-replication provides readable secondary replicas in other regions for DR and read scaling, but it does not support multi-master writes. Only the primary database accepts writes; secondaries are read-only. This can meet low-latency reads if users read from a nearby secondary, but it fails the multi-master write requirement.

Azure SQL Database Hyperscale is a tier optimized for very large databases and rapid scale, with architecture that separates compute and storage and can use read replicas. However, it still follows a single-writer model and does not provide multi-master writes across regions. It can help with read performance and scale, but it doesn’t meet the multi-master requirement.

Azure Database for PostgreSQL supports standard SQL and can provide read replicas for scaling reads, but the managed service does not natively provide multi-master, multi-region writes as a built-in feature. Typical HA/DR patterns are single primary with replicas. Achieving multi-master would require complex custom replication/conflict handling, which is not the intended managed solution.

Azure Notification Hubs is a push notification service for sending messages to mobile devices (iOS/Android) and browsers. It is optimized for fan-out notifications to users, not for reliable service-to-service transactional messaging. It lacks core broker capabilities like queues/topics with dead-lettering, sessions, and enterprise delivery semantics required for order/billing/payment workflow integration.

Azure Data Lake (Azure Data Lake Storage Gen2) is designed for big data analytics storage (Hadoop/Spark), storing large volumes of structured/unstructured data for batch and analytical workloads. While it can store XML files, it is not a messaging system and does not provide asynchronous broker features such as message locks, retries, subscriptions, or guaranteed delivery patterns for microservices.

Azure Blob Storage is object storage for unstructured data (files, documents, logs). You could store XML documents and have services poll for changes, but that is inefficient and lacks messaging guarantees, consumer coordination, and built-in retry/dead-letter patterns. Blob Storage is not intended as a message broker for transactional workflows; it’s primarily for storage, not asynchronous integration.

Azure SQL Database Serverless is a compute tier within General Purpose that auto-scales and can auto-pause to reduce cost for intermittent usage. It is not designed to guarantee zero data loss failover between replicas, and it does not inherently provide zone-resilient synchronous replicas. It addresses cost optimization for variable workloads, not strict HA requirements like RPO=0 plus zone-outage survivability.

Azure SQL Database Basic is intended for small, less demanding workloads and does not provide the multi-replica synchronous architecture needed for zero data loss failover. It also does not support the advanced HA/zone redundancy capabilities required to remain available through a zone outage. While it minimizes cost, it fails the reliability requirements.

Azure SQL Database Standard is a lower service tier intended for general-purpose workloads and does not provide the same synchronous multi-replica high-availability architecture as Business Critical. Because of that, it is not the right choice when the requirement explicitly calls for failover between replicas with no data loss. It also does not offer the same level of zone-resilient availability expected for mission-critical database workloads. While it is less expensive, it does not satisfy the stated resiliency requirements.

An Azure App Service web app is a managed PaaS offering that minimizes maintenance, but it does not provide customer applications with direct access to the Windows Application event log. App Service does offer temporary local storage, but that only satisfies one of the two technical requirements. Replacing event log writes with App Service diagnostics or Application Insights would require changing the application's behavior, which the question does not permit. Therefore, App Service cannot fully meet the stated requirements even if it is cheaper and easier to manage.

An App Service Environment is still based on Azure App Service, so it has the same platform limitation regarding direct access to the Windows Application event log. It provides isolation, networking control, and dedicated capacity, but not guest OS-level control for writing to Event Viewer. In addition, ASE is significantly more expensive than the other options and directly conflicts with the requirement to minimize costs. Since it fails both the technical fit and cost goals, it is not the right recommendation.

An Azure Functions app is a serverless compute option intended for event-driven execution patterns, not for hosting a traditional web service that depends on Windows OS features. Functions can use temporary local storage in limited ways, but they do not expose the Windows Application event log for application writes. As with App Service, using Application Insights instead would be a redesign rather than satisfying the explicit requirement. Therefore, Functions do not meet the requirement even though they can reduce operational overhead and cost for suitable workloads.

Role-based access control (RBAC) in Azure controls access to Azure resources (subscriptions, resource groups, SQL server resource) via the management plane. It does not, by itself, restrict what data a user can query inside Azure SQL Database. Data-plane permissions are handled by SQL logins/users, database roles, and features like DDM/RLS, not Azure RBAC alone.

Data Discovery & Classification helps you discover, label, and track sensitive data columns (like PII) in Azure SQL. It supports governance, reporting, and can drive recommendations (e.g., in Microsoft Defender for SQL), but it does not enforce that only privileged users can view the data. It’s a complementary governance feature, not an access control mechanism.

Transparent Data Encryption (TDE) encrypts the database, logs, and backups at rest to protect against offline access to files or backups. However, it does not prevent users who can query the database from seeing PII in results. TDE addresses at-rest encryption requirements, not selective visibility for privileged vs. non-privileged users.