Task 2.2: Implement security for databases

• ASwitch TDE to a service-managed key first, then repair the key vault role

  Incorrect

  Changing the protector needs access to the current key, and it doesn't stop the clock on the lost access.

• BRestore the role assignment now, before 30 minutes have passed

  Correct

  If key access is restored within 30 minutes, the databases heal automatically within the next hour.

• CWait a few minutes for the databases to recover on their own

  Incorrect

  With the role still removed, key access doesn't come back on its own.

• DRestore the databases from the latest point-in-time backup on a new server

  Incorrect

  A restore is slow and still needs the key, while restoring access quickly avoids it.

With a customer-managed TDE protector, the server needs continuous access to the key. After a Key Vault error such as a 4XX caused by missing permissions, databases move to Inaccessible after 30 minutes. If access is restored within 30 minutes, they heal automatically within the next hour; after that, automatic healing isn't possible and recovery needs extra, time-consuming procedures.

• AThe Directory Readers role to the pipeline's service principal

  Incorrect

  The lookup is made by the server's identity, and Directory Readers is the broader option.

• BThe Directory Readers role to the server's identity

  Incorrect

  This works, but Azure SQL Database supports narrower Graph permissions, which least privilege prefers.

• CGlobal Reader to the pipeline's service principal

  Incorrect

  A directory role on the pipeline doesn't give the server what it needs, and it reads far more than required.

• DMicrosoft Graph User.Read.All, GroupMember.Read.All and Application.Read.All to the server's identity

  Correct

  Azure SQL Database supports these fine-grained permissions on the server identity, the recommended least-privilege setup.

For some operations, such as a service principal creating Microsoft Entra users, Azure SQL Database queries Microsoft Graph through the server identity. Azure SQL Database supports fine-grained Graph permissions (User.Read.All, GroupMember.Read.All, Application.Read.All) assigned to the server identity, which Microsoft recommends; SQL Managed Instance needs Directory Readers or equivalent permissions.

• AFirewall rules can't be added, removed or edited while public network access is disabled

  Correct

  Managing server or database-level firewall rules needs the public network interface enabled.

• BThe pipeline's identity lost SQL Server Contributor when the private endpoint was created

  Incorrect

  Creating a private endpoint doesn't change role assignments.

• CWith public access off, server-level rules must be created with T-SQL in master

  Incorrect

  With public access disabled, rule changes are refused by any method.

• DFirewall rules need the connection policy changed from Default to Proxy

  Incorrect

  The connection policy decides how clients connect, not whether firewall rules can be managed.

When Public network access is set to Disable, only private endpoint connections are allowed, and any attempt to add, remove or edit firewall rules is denied with error 42101. To manage firewall rules again, public network access must be set to Selected networks; with private endpoints in place, the pipeline's firewall steps are no longer needed.

• ADisable server-level auditing and keep the database-level policies

  Incorrect

  Server-level auditing also covers databases created later; Microsoft recommends keeping it and disabling database-level auditing.

• BKeep both, because database-level auditing replaces the server policy for those databases

  Incorrect

  Database-level auditing doesn't override the server policy; both run side by side.

• CDisable database-level auditing on the databases and keep server-level auditing

  Correct

  With both enabled, each database is audited twice in parallel.

• DChange the database-level destination to Event Hubs so that the logs no longer overlap

  Incorrect

  A different destination still audits every event twice.

A server auditing policy applies to all existing and new databases on the server, regardless of database settings. Enabling database-level auditing as well doesn't change the server audit: the database is audited twice in parallel. Microsoft recommends enabling only server-level auditing, unless a database needs a different destination, retention or event types.

• AThe server's managed identity holds Storage Blob Data Contributor on the storage account

  Correct

  Auditing to a firewalled account authenticates with the server's managed identity and this role.

• BThe SQL server gets a private endpoint in the storage account's virtual network

  Incorrect

  A private endpoint for the SQL server isn't what lets auditing reach the storage account.

• CThe storage account allows the SQL server's outbound public IP address

  Incorrect

  Audit writes don't rely on an IP rule; they rely on the trusted services exception.

• DThe auditing configuration includes a storage access key as a fallback

  Incorrect

  Access keys aren't used for firewalled accounts and are forbidden here.

• EThe storage account allows trusted Microsoft services to access it

  Correct

  This exception is required on the storage firewall for audit writes.

When the audit storage account is behind a virtual network or firewall, auditing must use managed identity authentication: the server's identity gets Storage Blob Data Contributor, and no storage access key is specified. The storage account must allow trusted Microsoft services to access it, and it must be general-purpose v2.

• AAll three accounts

  Incorrect

  Not every Cosmos DB API is supported by the plan.

• BOnly the NoSQL account

  Correct

  Azure Cosmos DB for NoSQL is the supported API.

• CThe NoSQL and MongoDB accounts

  Incorrect

  Azure Cosmos DB for MongoDB isn't supported.

• DNone until each account enables diagnostic logs

  Incorrect

  The plan doesn't depend on diagnostic logs being enabled.

Defender for Azure Cosmos DB detects potential SQL injection, known bad actors and suspicious access patterns without accessing account data or affecting performance. It supports Azure Cosmos DB for NoSQL; the Apache Cassandra, MongoDB, Table and Apache Gremlin APIs aren't supported.

• A256

  Correct

  A server can have up to 256 server-level IP firewall rules.

• B64

  Incorrect

  The limit is higher.

• C1,000

  Incorrect

  The limit is lower.

• DThere's no limit

  Incorrect

  Server-level rules are limited per server.

A logical server can have up to 256 server-level IP firewall rules, and the Allow Azure services and resources to access this server setting counts as one of them. Database-level rules have their own limit per database.

• ASelf-managed MySQL on any Linux server

  Incorrect

  The documented non-Azure targets are managed Amazon RDS engines.

• BGoogle Cloud SQL for PostgreSQL

  Incorrect

  The documented non-Azure targets are on AWS.

• COracle Database on Amazon RDS

  Incorrect

  Oracle isn't among the supported engines.

• DAmazon RDS for PostgreSQL, MySQL and MariaDB, and Aurora PostgreSQL and MySQL

  Correct

  These Amazon RDS engines are supported.

Besides Azure Database for PostgreSQL and MySQL flexible servers, Defender for Open-Source Relational Databases supports Amazon RDS instances for Aurora PostgreSQL, Aurora MySQL, PostgreSQL, MySQL and MariaDB, with multicloud alerts and sensitive data discovery.

• ATemporal and in-memory ledger tables

  Incorrect

  Those aren't the ledger table types.

• BEncrypted and masked ledger tables

  Incorrect

  Encryption and masking are separate features.

• CLocal and distributed ledger tables

  Incorrect

  Those aren't the ledger table types.

• DUpdatable and append-only ledger tables

  Correct

  Updatable tables keep row history; append-only tables allow only inserts.

Ledger comes in two kinds of tables: updatable ledger tables, which allow updates and deletes and keep previous row versions in a history table, and append-only ledger tables, which allow only inserts. Both provide tamper evidence.

• AIt allows only resources in your own subscription

  Incorrect

  It isn't limited to your subscription.

• BIt creates private endpoints for Azure services

  Incorrect

  It's a public endpoint setting, not Private Link.

• CIt lets other resources within the Azure boundary connect through the public endpoint

  Correct

  For example, an Azure VM can then reach the server.

• DIt allows trusted Microsoft services only

  Incorrect

  It isn't a trusted-services list like the storage exception.

Allow Azure services and resources to access this server lets other resources within the Azure boundary, such as an Azure VM, access the server through its public endpoint. It's set to No by default when you create a server in the portal and counts as one server-level firewall rule.