Microsoft SC-500 Practice Test 18

Question 170

An Azure SQL Database investigator can read approved SQL reporting tables, but mistakenly expects that database read permission to permit downloading SQL audit .xel evidence. The audit policy writes files into a separate private Azure Blob container. Which authorization approach retrieves the audit evidence without granting production database administration?

Enable another SQL auditing action group; the new event selection automatically gives the investigator Azure Storage Blob data access.
Enable anonymous public read for the audit container so SQL database role assignments are no longer relevant.
Give the investigator SQL db_owner so its SQL permission can override Azure Blob storage container access policies.
Treat the audit destination as an Azure Storage resource: grant scoped Blob data-read access to the actual audit container and an approved private network path, without increasing SQL database roles.

Explanation

Correct Answer

SQL database read permissions and Blob data permissions are separate authorization planes. Inspect the configured audit sink and give the investigator only Storage data-read access at that container plus its permitted network path; the SQL production privilege set remains unchanged.

Incorrect Answers

SQL audit action groups specify which database events are collected; they do not grant Azure Storage data access to the resulting .xel objects. The investigator would still lack the Blob role or permitted network route.

Public anonymous reads would disclose potentially sensitive audit actor and statement evidence. Correct the evidence-reader role on the private sink instead of bypassing data authorization or publishing logs.

db_owner expands SQL schema and data authority, but it does not confer Azure Storage Blob data-role membership. It would therefore expose production data while leaving the external audit-file read problem unresolved.

Question 171

A SQL auditing feature is enabled but known test queries produce no recorded audit events. Select THREE checks that establish the audit scope, event selection and actual delivery to its intended destination.

Switch on every audit category for every database without determining the test statement’s actual audit action group or destination.
Confirm SQL auditing is enabled for the particular database or managed instance where the test statement ran.
Execute a known auditable test action and verify that its event category is selected and emitted by the effective policy.
Verify the configured destination receives and retains the test events.
Treat auditing as detection/evidence; apply input validation and proper least-privilege authorization too.
Lengthen SQL audit-log retention without confirming the failing events were generated or delivered.

Explanation

Correct Answer

Confirm that the effective auditing configuration applies to the database or managed instance on which the known test statement actually executed.

Run a statement that should be audited and verify the effective audit action group/event classification includes it; use that event to trace the pipeline.

Query the configured Storage, Log Analytics or Event Hubs destination for the test interval and confirm that the emitted event actually arrives and remains accessible.

Incorrect Answers

Enabling every audit category without identifying the intended action or destination wastes resources and hides the underlying collection fault.

Input validation and database authorization are vital controls, but their correctness cannot prove whether this SQL auditing pipeline is emitting records.

Increasing retention cannot create missing audit events when collection, action-group selection or delivery is broken.

Question 172

Investigators suspect an Azure SQL database role was altered to grant excessive privileges. Auditing was already enabled for appropriate permission-change activity. Which analysis best establishes WHO changed the grant and WHEN?

Assume that a clean database vulnerability assessment proves no role grant was changed during the incident window.
Query the retained SQL audit events for role/permission changes, correlate principal identity and timestamp with successful sign-in activity, and compare the resulting grants.
Inspect the server TLS configuration only; an encrypted connection identifies which user authorized a database role change.
Disable the detailed permission-change audit group to reduce events before beginning the privilege investigation.

Explanation

Correct Answer

Audit action records can identify the statement, identity and event time where configured to capture the relevant class. Correlate those entries with login context and the actual role-membership state, noting any missing records rather than inferring an actor from unrelated events.

Incorrect Answers

A vulnerability assessment evaluates posture and configurations at its scan time. It is not a historical event ledger that identifies the principal who executed a specific SQL grant or role change.

TLS secures the transport channel and may authenticate the server. It does not replace database audit events or link a specific permission-changing statement to the authenticated SQL principal and timestamp.

Disabling permission-change evidence during an investigation can remove the very security events needed to establish the actor and chronology. Noise tuning is a separate planned step after material evidence is preserved.

Question 173

An Azure SQL Database team switches SQL audit delivery from Blob storage to a Log Analytics workspace for centralized investigations. The SQL auditing toggle reads On, but no rows appear in the intended workspace. What end-to-end validation is required?

Create a Log Analytics workspace but omit the SQL diagnostic setting and assume the audit toggle directs events to any available workspace.
Verify the effective SQL audit policy and SQLSecurityAuditEvents diagnostic destination, trigger a test event, inspect its ingested table, and validate workspace access and retention.
Turn on additional transparent data encryption settings; encrypted-at-rest SQL data automatically generates and forwards audit records.
Rotate the storage account access key used by the old Blob destination and assume the new Log Analytics path automatically becomes active.

Explanation

Correct Answer

SQL auditing to Log Analytics depends on an effective SQL auditing configuration plus its Azure Monitor diagnostic setting. Validate an emitted event through the correct workspace/table, then verify RBAC and retention where investigators will actually query it.

Incorrect Answers

A workspace does not ingest database security audit events merely because it exists. The correct audit destination and diagnostic setting are needed; deleting the setting can silently stop delivery.

TDE protects disk pages and backups. It is neither an event collector nor an Azure Monitor pipeline, so changing TDE cannot repair the missing Log Analytics audit records.

The old Blob output credential governs a different destination and cannot establish that the Azure Monitor diagnostic pipeline is configured or receiving SQLSecurityAuditEvents.

Question 174

A finance database produces a high volume of Azure SQL audit events, including repetitive low-value statements. Security must retain failed logins and privileged changes without shutting off evidence collection. Which operational change fits?

Give all database operators access to the audit-storage account so they can manually delete events they consider noisy.
Increase audit-log retention from 30 to 365 days but leave all unnecessary event categories enabled and ignore the collection-noise problem.
Review the recorded action groups and refine audit selection to preserve security-relevant activity, then test that required events still reach the retained destination.
Disable SQL auditing for the entire server until an actual breach is detected, because the database remains encrypted at rest.

Explanation

Correct Answer

Source-specific audit event selection can reduce noise without eliminating required incident evidence. Determine which statements matter, adjust supported audit actions/groups using change control, and execute representative failed-login and privilege-change tests to verify retained visibility.

Incorrect Answers

Ad hoc deletion by broad-access database operators damages audit integrity and accountability. Triage should occur through reviewed event filtering and retention policies rather than removing evidence after the fact.

Longer retention may satisfy policy but does not change the number or relevance of ingested events. The issue is event selection and review workload, so simply retaining noise longer is not a remedy.

Turning auditing off removes detection and forensic context for the very high-risk events the organization must keep. At-rest encryption does not record which principal attempted an authentication or changed authorization.

Question 175

An engineer copies the Azure SQL Database logical-server auditing setup into an Azure SQL Managed Instance and expects identical SQL audit statements and target configuration. Which check prevents a Managed Instance audit gap?

Only change the Managed Instance firewall rule; TCP reachability automatically creates and enables its required database activity audit.
Grant the audit reviewer broad access to every production table before checking whether Managed Instance actually emits security audit events.
Reuse a SQL Database logical-server auditing toggle as the complete Managed Instance audit, without creating a SQL Server Audit or appropriate specification.
Use the Azure SQL Managed Instance SQL Server Audit procedure: verify supported CREATE SERVER AUDIT target (TO URL or EXTERNAL_MONITOR), enabled audit specifications, required permissions, and actual destination records.

Explanation

Correct Answer

Managed Instance uses SQL Server Audit semantics with supported audit targets and specifications. Confirm the instance-specific T-SQL configuration, credentials or identities and monitored destination, then generate an audited test action and verify its recorded event.

Incorrect Answers

Network access to a database cannot configure an audit definition or a server/database audit specification. A reachable instance can still fail to emit or forward required events.

Granting query permissions to investigators is unrelated to producing the audit trail and unnecessarily widens access. Verify event creation and protected audit sink first, then grant log-review permissions at their actual location.

Azure SQL Database audit UI behavior is not proof that equivalent SQL Server Audit objects and specifications exist on Managed Instance. Without the appropriate instance setup, event selection and output can be missing.

Question 176

An Azure SQL audit sink stores potentially sensitive statement and identity evidence in Blob storage. The audit container permits anonymous public reads. Which response closes the evidence-exposure gap while preserving incident investigations?

Give a security team Storage Blob Data Reader but leave anonymous public reads enabled for everyone else.
Increase the number of SQL audit action groups while leaving the existing public storage URL reachable.
Rotate the application SQL password while keeping the audit container and its previously written files public.
Disable anonymous Blob/container access, scope authenticated audit-reader permissions, and protect destination network access, retention and integrity where required.

Explanation

Correct Answer

Audit evidence should be readable only by authorized responders. Disable public anonymous paths at the account/container level, apply narrow Storage data roles, and check network and tamper-protection settings so evidence is both confidential and available for investigations.

Incorrect Answers

Granting a legitimate reader role does not remove an already active anonymous access path. Public visitors could still download audit evidence without using the new permission.

Additional action groups can produce more security events, but they do not change the storage endpoint ACL. The exposed audit log objects would remain publicly downloadable.

SQL credentials protect database authentication and do not revoke anonymous permissions on a separate Azure Blob container. Existing audit objects would still leak actor and statement details.

Question 177

A database owner believes SQL auditing prevents SQL injection. Select TWO controls or explanations that distinguish input safety and least-privilege execution from audit evidence.

Enable extra SQL audit categories and assume that recorded malicious statements are automatically blocked before execution.
Protect SQL operations with validated parameters and least-privileged database permissions.
Verify actual destination retention and access controls rather than only the Azure SQL auditing toggle.
Confirm product-specific auditing configuration and output support.
Continue using auditing as an investigation and detection record, not as input validation.

Explanation

Correct Answer

Use parameterized SQL and validate inputs, while granting the application only the database permissions needed to limit exploitation impact.

Keep SQL auditing for detection and forensic reconstruction; it records selected operations rather than sanitizing input or blocking injection.

Incorrect Answers

Adding audit events may capture an injection attempt, but it does not automatically stop a vulnerable query before SQL execution.

Log retention and repository access make evidence useful later, but do not transform an audit record into query-level protection.

Checking auditing support does not prevent untrusted SQL text being concatenated into executable statements.

Question 178

Azure SQL Database auditing already emits test records to its configured Blob storage account. An evidence policy requires those records to remain retrievable for 365 days, yet the only proof offered is that the SQL auditing toggle is On. Which acceptance test proves retention?

Verify only a Log Analytics table retention setting, even though the organization stores these specific SQL audit records exclusively in Blob storage.
Inspect stored test-event blobs, the effective Blob audit retention/lifecycle and access policies, and demonstrate authorized retrieval at the required retention boundary or through applicable policy evidence.
Read the Azure SQL Managed Instance audit target settings, although this workload is Azure SQL Database and its actual storage destination is known.
Recheck whether a failed-login action group is enabled, even though representative audit events have already been observed in the intended Blob destination.

Explanation

Correct Answer

The compliance requirement concerns persisted evidence, not the audit switch. Confirm which Blob objects are retained, how lifecycle or audit retention deletes them, who can read them and whether immutability/legal retention is required for the policy; test the actual access path.

Incorrect Answers

Log Analytics retention can matter for workspaces that receive SQL events, but it cannot prove 365-day storage for records sent only to this Blob account. The correct sink and its lifecycle settings must be examined.

Managed Instance can use different audit objects and sinks, but those settings do not establish retention on the Azure SQL Database Blob storage account being audited in this case.

Audited event-category selection matters before verifying an end-to-end audit trail, but the scenario already confirms event delivery. That check does not prove historical audit blobs survive 365 days.

Question 179

An Azure SQL Database emits suspicious authentication patterns. Which configuration or verification action best fits the scenario?

Use the applicable Defender for Cosmos DB plan rather than SQL-only protection.
Infer that a suspicious login is confirmed compromise using only SQL query-performance statistics, without reviewing Defender for SQL alerts or audit evidence.
Review corresponding Defender for SQL alerts and related SQL audit events.
Identify the database and server protection prerequisites for hybrid SQL threat detection.

Explanation

Correct Answer

Review the corresponding Defender for SQL alerts and corroborate them with Azure SQL audit records, source principal and relevant time window.

Incorrect Answers

Defender for Cosmos DB does not interpret the Azure SQL Database suspicious authentication activity described.

Inferring compromise only from query performance or a generic database anomaly, without the specific Defender for SQL alert and audit evidence, is not a sound investigation.

Hybrid SQL threat-protection onboarding applies to other SQL hosting models and does not replace analysis of alerts already emitted by Azure SQL Database.

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

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

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.

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.

Defender for Azure Cosmos DB is a different workload plan; SQL-like query operations do not enable Azure SQL Database anomalous-activity alerts.

Implementing End-to-End Security Controls for Cloud and AI Workloads (SC-500) Practice Tests

Microsoft SC-500 Practice Test 16 - 10 Questions (Last Reviewed 29-Oct-2026)
Microsoft SC-500 Practice Test 17 - 10 Questions (Last Reviewed 28-Oct-2026)
Microsoft SC-500 Practice Test 18 - 10 Questions (Last Reviewed 27-Oct-2026)
Microsoft SC-500 Practice Test 19 - 10 Questions (Last Reviewed 26-Oct-2026)
Microsoft SC-500 Practice Test 20 - 10 Questions (Last Reviewed 25-Oct-2026)

Pass Your Microsoft SC-500 Exam Easy!

Question 170

Explanation

Correct Answer

Incorrect Answers

Question 171

Explanation

Correct Answer

Incorrect Answers

Question 172

Explanation

Correct Answer

Incorrect Answers

Question 173

Explanation

Correct Answer

Incorrect Answers

Question 174

Explanation

Correct Answer

Incorrect Answers

Question 175

Explanation

Correct Answer

Incorrect Answers

Question 176

Explanation

Correct Answer

Incorrect Answers

Question 177

Explanation

Correct Answer

Incorrect Answers

Question 178

Explanation

Correct Answer

Incorrect Answers

Question 179

Explanation

Correct Answer

Incorrect Answers

Question 180

Explanation

Correct Answer

Incorrect Answers

Implementing End-to-End Security Controls for Cloud and AI Workloads (SC-500) Practice Tests