Question 180
Azure SQL Database auditing is already writing statement and SQL login records to Blob storage, yet the SOC expects those audit records to AUTOMATICALLY become Microsoft Defender for SQL anomalous-activity alerts. No Defender SQL threat plan is enabled. Which explanation identifies the missing, SEPARATE detection mechanism?
- Deploy a Defender for SQL Servers on Machines extension directly to the Azure SQL Database logical server as though it were a managed Windows VM.
- Increase the SQL audit categories until each recorded event automatically becomes a Defender for SQL anomalous-activity alert without enabling a separate threat plan.
- Enable Azure Cosmos DB threat protection and assume SQL-like query syntax makes those detections apply to Azure SQL Database.
- Recognize that SQL auditing records selected database operations; anomaly threat alerts require the separate Microsoft Defender for Azure SQL Databases protection plan and verified coverage.
Explanation
Correct Answer
D:Azure SQL auditing writes selected events to a configured audit destination. Defender for SQL is an independent workload threat-protection plan for anomalous SQL activity; enable its Azure SQL Databases coverage rather than equating stored audit records with detection alerts.
Incorrect Answers
A:Defender for SQL Servers on Machines covers SQL engines running on supported machines. Azure SQL Database is managed PaaS, so adding a machine extension to its logical server is the wrong mechanism.
B:An audit sink can record database activity for investigation but does not automatically provision Microsoft Defender for SQL alert detection, regardless of the number of audit categories selected.
C:Defender for Azure Cosmos DB is a different workload plan; SQL-like query operations do not enable Azure SQL Database anomalous-activity alerts.
Question 181
A production fleet runs Azure Database for PostgreSQL Flexible Server. It has ordinary database logging but no Defender for Cloud threat detection coverage for suspicious database access. Which workload plan should be selected and verified?
- Enable the supported Defender for Open-Source Relational Databases protection for the PostgreSQL Flexible Servers and verify scoped assets and alert flow.
- Enable Microsoft Defender for Azure SQL Databases and assume it covers PostgreSQL Flexible Server instances under the same subscription.
- Enable Defender for SQL Servers on Machines and deploy SQL Server-specific monitoring extensions to each managed PostgreSQL Flexible Server.
- Increase the PostgreSQL statement logging level alone and claim Defender’s anomaly-based threats will be generated without a workload plan.
Explanation
Correct Answer
A:The Defender for Open-Source Relational Databases plan covers supported PostgreSQL Flexible Server tiers. Enable it where the assets reside, then confirm the instances appear protected and alerts reach the accountable response team.
Incorrect Answers
B:The Azure SQL plan is for SQL Database and related SQL PaaS offerings, not automatically for PostgreSQL. A subscription containing both services still requires the appropriate resource-type protection.
C:The machines plan is designed for SQL Server on supported VMs and Azure Arc SQL Server instances. PostgreSQL Flexible Server is a managed open-source relational database service and does not use that onboarding architecture.
D:Native PostgreSQL logs aid forensics but do not substitute for enabling the Defender product that detects supported anomalous activity. Logging volume and threat-alert coverage are separate control decisions.
Question 182
An Azure Cosmos DB account has suspicious key-enumeration and unusual-location events in its own telemetry. The organization currently enables only the Defender for Azure SQL Databases plan and wants workload-specific threat alerts for Cosmos DB. Which plan is required?
- Investigate only SQL Database audit files, since those contain all Azure Cosmos DB key enumeration attempts.
- Register the Cosmos DB account as an Azure Arc SQL Server instance so the SQL Servers on Machines plan can inspect it.
- Retain the Defender for Azure SQL Databases plan and assume it covers every database engine in the subscription.
- Enable Microsoft Defender for Azure Cosmos DB for the account or approved subscription scope, then review the Cosmos DB-specific alerts and detection coverage.
Explanation
Correct Answer
D:The Cosmos DB Defender plan detects suspicious access patterns, potential injection behavior and unusual account/key operations for supported Cosmos DB resources. Enable it at the intended scope and confirm the alerts are actually generated and routed for this account.
Incorrect Answers
A:Azure SQL audit output belongs to a different database service. Cosmos DB account telemetry and Defender for Cosmos DB alerts are the appropriate evidence sources for this detection and response requirement.
B:Azure Cosmos DB is a managed distributed database service, not an Arc-enabled SQL Server instance. Registering it as a SQL machine is not a supported route to Cosmos DB threat detection.
C:Defender plans are workload-specific. The PaaS Azure SQL plan does not grant Cosmos DB-native detections for suspicious locations, key access or anomalous document operations.
Question 183
An on-premises Microsoft SQL Server is connected to Azure Arc, but its SQL instance is missing from the protected SQL Server on machines inventory. A team assumes that Arc server connection alone enables database threat detection. What coverage prerequisites must be verified?
- Use the Azure SQL Database PaaS plan because the Arc-connected server appears in the Azure portal.
- Install Defender for Servers Plan 1 only and assume it includes all SQL-specific database threat detections without a Defender for Databases plan.
- Verify supported SQL Server instance discovery/registration through Arc, the Defender for SQL Servers on Machines plan under Defender for Databases, and required extensions, permissions and connectivity.
- Enable a SQL Database audit sink on an unrelated logical Azure SQL server and expect Arc SQL detections to start.
Explanation
Correct Answer
C:Defender for SQL Servers on Machines supports appropriately registered Arc SQL Server instances and SQL VMs. Verify the workload plan, instance inventory, required extensions/permissions and network endpoints, then check the instance is actually protected rather than merely Arc-connected.
Incorrect Answers
A:Azure portal visibility through Arc does not convert an on-premises SQL Server into Azure SQL Database. The PaaS plan will not provide the required machine-based SQL protection scope.
B:Defender for Servers can supply machine security benefits, but it does not automatically replace the SQL workload plan or its discovery/extension requirements. The SQL instance must be covered by the applicable Defender for Databases offering.
D:Audit settings on a separate SQL Database resource do not onboard this physical or virtual SQL Server. SQL auditing and Defender for SQL servers on machines protect different scopes and are configured separately.
Question 184
A workload moves from Azure SQL Database to Azure Database for MySQL Flexible Server. Defender for Azure SQL remains enabled for the original logical server, but the replacement database reports no Defender anomaly alerts. Which coverage validation explains the migration gap?
- Inventory the new database resource type and scope, reconcile its supported Defender plan and onboarding requirements, and verify new MySQL coverage and alert delivery.
- Keep only the original Defender for Azure SQL Databases plan and change its SQL audit retention; the target MySQL service automatically inherits the old plan.
- Investigate SQL-specific alerts on the old logical server and declare the new MySQL resource protected once the old alerts have been acknowledged.
- Deploy Defender for SQL Servers on Machines to the fully managed MySQL Flexible Server and assume its SQL Server extensions are compatible.
Explanation
Correct Answer
A:Moving between database products changes the applicable Defender plan and potentially the onboarding scope. The team should match the target to the supported open-source relational database protection, enable any missing coverage and verify actual new-service alerts.
Incorrect Answers
B:Old Azure SQL Defender enablement and audit retention do not automatically transfer threat protection to a different database engine. The plan must be applicable to the new MySQL resource.
C:Historical SQL Server alerts describe the old workload and do not establish monitoring for a MySQL Flexible Server after migration. Coverage must be assessed against the new resource identity and service type.
D:Defender for SQL on Machines applies to supported SQL Server installations, not the MySQL Flexible Server managed service. The Microsoft SQL Server agent model is not compatible with the destination workload type.
Question 185
Defender for SQL flags a potential SQL injection against an Azure SQL Database. Application logs label the request as an expected query, but the alert includes an unfamiliar client source and suspicious input payload. Which action should precede either dismissal or containment?
- Correlate Defender alert evidence with SQL audit/query context, request parameters, effective principal and source identity; assess whether the behavior was malicious before recording a verdict.
- Enable SQL Server on Machines extensions on the PaaS Azure SQL Database and treat extension installation as proof the alert is benign.
- Dismiss the Defender alert based only on the application log label and suppress future alerts of the same name.
- Re-enable the Defender for Azure SQL Databases plan even though it already produced the alert, without examining the underlying request.
Explanation
Correct Answer
A:Threat triage compares the alert details with the executed statement, parameters, identity, source IP and application intent, and checks whether dangerous behavior occurred. A legitimate log description is evidence to weigh, not a reason to assume compromise or benign activity.
Incorrect Answers
B:Azure SQL Database is a managed PaaS offering, not a SQL Server VM needing the on-machines extension. Deploying an unrelated agent cannot validate the semantics of this security alert.
C:Application logs can omit query parameters or provide misleading labels. Immediate dismissal without source, SQL context and request correlation can overlook an actual injection attempt or malicious client.
D:The plan is already active because it emitted this detection. Re-enabling it does not establish whether the payload was an exploit, a safe parameterized test or a false positive.
Question 186
After a Defender for SQL-related database vulnerability finding was remediated by patching, a legacy database role still grants unnecessary elevated permissions. Which action actually closes the remaining authorization risk?
- Assign a SOC owner to the historical Defender alert while leaving the overprivileged SQL role intact.
- Treat closure of the patch-related alert as automatic revocation of all outdated SQL role permissions.
- Enable a separate Defender for SQL on machines plan even though this case concerns a known excessive role on an already managed database.
- Review the effective SQL grants and role memberships, revoke the legacy excess permissions, and verify only authorized principals retain the required database rights.
Explanation
Correct Answer
D:Fixing code or applying patches does not edit SQL authorization grants. Identify the stale role and its members, remove its unnecessary permissions or membership, and test that required functions continue under least privilege.
Incorrect Answers
A:Alert ownership is important for investigation accountability, but cannot prevent a legacy role from reading or modifying database data beyond business need. The permission set remains the defect.
B:Threat or posture alert resolution and database permissions are separate state changes. An audit of actual effective role membership is needed after the patch to confirm that excess rights no longer exist.
C:Changing Defender product coverage does not rewrite the existing SQL role grants. Machine-based threat protection would not repair an already identified database authorization flaw.
Question 187
A high-value Azure SQL Database already sends Defender for SQL alerts into a STAFFED SOC incident queue and delivery tests pass. Yet critical database incidents remain unassigned because the SOC has no SQL-alert owner, response SLA or escalation rule. Which change closes this accountability gap?
- Reconfigure the already functioning alert forwarding endpoint but leave all incidents without named ownership or response expectations.
- Assign explicit SQL-alert triage ownership, severity-based response and escalation responsibilities, and validate the incident-assignment process with a test case.
- Move the Azure SQL workload to a PostgreSQL threat-protection plan, since a change of detector automatically assigns a SOC case owner.
- Re-onboard the PaaS SQL database as an Azure Arc SQL Server machine even though its current Defender alerts reach the queue.
Explanation
Correct Answer
B:An alert that reaches an SOC queue still needs accountable human ownership and escalation. Define a SQL-database response runbook, incident assignment and severity SLA; test that a high-severity case is claimed and escalated when not acknowledged.
Incorrect Answers
A:No transport or mailbox delivery failure remains in this case. Changing the integration endpoint cannot make a named analyst accountable, enforce timely escalation, or prove the ownership workflow works.
C:PostgreSQL protection is designed for a different database service. Switching to an unrelated plan neither preserves SQL detection coverage nor specifies who must respond to the existing finance-database alerts.
D:Azure Arc server onboarding does not designate who must triage an incident. This Azure SQL Database already has successful PaaS alert delivery, so treating it as an SQL Server VM addresses the wrong workload and failure mode.
Question 188
A subnet hosts web and database VMs but only web instances may receive internet HTTP. Which control best addresses the actual risk described?
- Use supported ASGs to group NICs by application role for NSG rules.
- Check stateful connection behavior and effective inbound/outbound policy instead of broad Allow Any.
- Create narrow inbound NSG rules and deny direct internet database access.
- Inspect separate outbound NSG rules and default outbound behavior.
Explanation
Correct Answer
C:Configure narrowly scoped inbound HTTP allowances for web instances and deny direct internet access to database instances; verify effective precedence.
Incorrect Answers
A:ASGs can help group web and database NICs, but group membership alone does not enforce an inbound allow/deny NSG rule.
B:Examining stateful behavior is useful diagnostic work but is not a network segmentation rule protecting databases from new internet HTTP requests.
D:Outbound security-rule evaluation is separate from ensuring that only the web NICs receive allowed inbound internet HTTP.
Question 189
A new inbound TCP 443 connection to an Azure VM encounters a matching subnet NSG Deny, while the VM NIC NSG has a matching Allow for the same flow. What explains the failure and guides the narrowest authorized fix?
- Evaluate the subnet and NIC rules together: the subnet Deny can block despite the NIC Allow. Verify the applied rule and correct only the approved subnet restriction.
- Remove all subnet NSGs across the virtual network to guarantee HTTPS reachability without checking applied policies.
- Add an even higher priority NIC Allow and assume it overrides the matching subnet-level Deny.
- Inspect only the NIC NSG and conclude traffic succeeds because its Allow matches the packet.
Explanation
Correct Answer
A:NSGs at subnet and NIC scopes are both applied to inbound network traffic, and a matching subnet Deny stops this new inbound TCP 443 flow even if the NIC rules later say Allow. Check the effective rules for the actual NIC, confirm the denied source and port, and amend only the authorized subnet policy rather than broadening all network access.
Incorrect Answers
B:Removing every subnet NSG creates a large unrelated exposure and is unnecessary. The case names one matching subnet Deny, so investigate and narrowly correct that security decision, retaining all other intended subnet and interface restrictions.
C:An Allow in the VM NIC NSG does not cancel a Deny enforced by the associated subnet NSG for this inbound packet. Adding another NIC rule cannot make the subnet path permit traffic; inspect the relevant applied subnet rule and central admin policy first.
D:Looking at only the NIC NSG misses the explicitly stated subnet-level Deny. The traffic must be permitted by the relevant subnet and NIC rule evaluations; a NIC Allow alone is not proof of end-to-end inbound reachability.
Question 190
For a new inbound TCP flow, the SAME Azure NSG has a matching custom Deny rule at priority 100 and a matching Allow rule at priority 200. There is no earlier admin-rule decision. What is the NSG outcome?
- The connection is permitted if the subnet is in an ASG, because ASG membership overrides an explicit matching NSG Deny.
- The priority 100 Deny matches first and blocks the flow; the overlapping priority 200 Allow is not evaluated.
- Azure evaluates both rules and takes whichever has the later creation timestamp, regardless of its numeric priority.
- The priority 200 Allow overrides Deny because Allow is considered more permissive regardless of priority.
Explanation
Correct Answer
B:NSG custom rules are processed from lower numeric priorities to higher numbers and stop on the first match. The Deny at 100 therefore terminates the inbound decision before the rule at 200 can permit traffic.
Incorrect Answers
A:Application security groups can be used as source or destination selectors within NSG rules. They do not grant immunity from an explicit Deny rule that matches the flow.
C:Rule creation time is not the documented NSG precedence mechanism. Azure uses the rule priority and packet five-tuple; this scenario specifies a unique earlier Deny.
D:Allow and Deny are not resolved by a blanket allow-wins preference. An Allow at a numerically higher priority value is never reached once the earlier Deny matches the same packet.
Implementing End-to-End Security Controls for Cloud and AI Workloads (SC-500) Practice Tests