Database Security practice questions

Modify the network ACL for the DB subnet to allow inbound port 3306 from the EC2 instance's private IP.

Why wrong: Network ACLs are stateless and require separate inbound and outbound rules; security groups are more appropriate for this use case.

Modify the DB subnet group to place the RDS instance in a public subnet with a route to the EC2 instance.

Why wrong: Placing the database in a public subnet is insecure and unnecessary; subnet group changes do not affect security group rules.

Add an inbound rule to the RDS security group allowing traffic from the VPC CIDR on port 3306.

Why wrong: This would still allow any resource in the VPC, which is broader than needed.

Enable encryption at rest using AWS KMS with a CMK and use column-level encryption with AWS KMS to restrict access.

Why wrong: DynamoDB does not support column-level encryption; encryption is table-wide.

Attach a resource-based policy to the DynamoDB table that grants access only to the specific IAM roles.

Why wrong: A resource-based policy alone does not enforce encryption requirements.

Use a DynamoDB Accelerator (DAX) cluster with encryption at rest using a CMK, and attach a resource-based policy to the table.

Why wrong: DAX does not support customer-managed CMKs for encryption at rest.

Configure the DynamoDB table to use AWS KMS encryption with a CMK, and attach a key policy to the CMK that allows only the specific IAM roles.

Why wrong: The key policy controls who can use the CMK, but does not restrict which IAM roles can access the DynamoDB table.

Launch the RDS instance in the default VPC.

Why wrong: Placing the instance in a different VPC would complicate connectivity.

Change the DB subnet group to include the application server's subnet.

Why wrong: The DB subnet group defines which subnets the RDS instance can be in, not which subnets can connect to it.

Add a network ACL rule allowing inbound traffic on port 5432 from the application server's public IP.

Why wrong: Network ACLs are stateless and the application uses private IP; also security groups are sufficient.

Modify the RDS instance to be publicly accessible.

Why wrong: Public accessibility is not needed if the application is in the same VPC.

The CloudWatch Logs log group does not exist and RDS cannot create it automatically.

Why wrong: RDS can create the log group automatically if the IAM role has sufficient permissions.

The DB cluster is not configured to export error logs, only audit logs.

Why wrong: The issue is about audit logs not appearing, not error logs.

CloudWatch Logs does not support encryption with customer-managed KMS keys for audit logs.

Why wrong: CloudWatch Logs does support customer-managed KMS keys.

The audit log parameter is static and requires a DB cluster reboot after modification.

Why wrong: Some audit log parameters are dynamic and do not require reboot; but the issue is not about parameter modification.

Update the Redis parameter group to enable the 'encryption-in-transit' parameter and reboot the cluster.

Why wrong: There is no such parameter; encryption in transit is a cluster-level setting.

Use a security group to enforce encrypted connections by allowing only TLS traffic.

Why wrong: Security groups cannot enforce encryption; they only filter traffic by IP and port.

Modify the existing Redis cluster to enable encryption in transit using the AWS CLI.

Why wrong: Encryption in transit cannot be modified on an existing cluster.

Enable encryption in transit on the existing cluster by using the AWS Management Console.

Why wrong: The console does not allow enabling encryption in transit on an existing cluster.

Use the RDS Console to enable 'Force SSL' on the DB instance.

Why wrong: The RDS Console does not have a 'Force SSL' option for SQL Server; it must be done via parameter group.

Modify the DB parameter group to set 'require_secure_transport' to ON.

Why wrong: 'require_secure_transport' is a MySQL parameter, not SQL Server.

Add an inbound rule to the security group that only allows traffic on port 1433 from IP addresses that use SSL.

Why wrong: Security groups cannot inspect whether traffic is encrypted; they only filter by IP and port.

Create a VPC endpoint for RDS and associate it with the DB instance.

Why wrong: VPC endpoints are not used for DB instances; they are for accessing AWS services privately.

Store the encryption key in Amazon S3 and configure RDS to use it.

Why wrong: KMS keys are not stored in S3; they are managed by KMS.

Create a password for 'app_user' and use that password in the connection string.

Why wrong: IAM database authentication does not require a password; the authentication token replaces the password.

Modify the security group to allow inbound traffic on port 3306 from the application's IP address.

Why wrong: Network connectivity is likely fine; the error is an authentication failure, not a connection timeout.

Download the latest Amazon RDS CA certificate and add it to the application trust store.

Why wrong: Certificate validation is for SSL connections, but the error is specifically about access denied, not SSL handshake failure.

Use client-side encryption for data before sending to RDS, and enable encryption at rest after the instance is created.

Why wrong: Client-side encryption does not encrypt the network transport; also, encryption at rest cannot be enabled after creation without a snapshot.

Launch the RDS instance without encryption, then enable encryption at rest using the AWS Console.

Why wrong: Encryption at rest can only be enabled at launch or by restoring an encrypted snapshot.

Use AWS KMS to encrypt the connection between the application and RDS.

Why wrong: KMS is for key management, not for encrypting connections; SSL/TLS should be used for in-transit encryption.

Modify the DynamoDB table to update the encryption key to the new CMK using the AWS Console.

Why wrong: DynamoDB does not support modifying the encryption key on an existing table.

Disable encryption at rest, then re-enable it with the new CMK.

Why wrong: Encryption at rest cannot be disabled on a DynamoDB table; it is always enabled.

Update the KMS key policy to grant DynamoDB access to the new CMK, then rotate the key.

Why wrong: The key policy change does not change the key used to encrypt the table; the table will still use the original key.

The application is using an outdated root CA certificate for SSL.

Why wrong: While SSL is required, the error is specific to authentication, not SSL handshake.

The Security Group does not allow inbound traffic from the application.

Why wrong: Network connectivity would cause a timeout, not an authentication error.

The RDS instance is using a different KMS key for encryption.

Why wrong: KMS keys are unrelated to IAM database authentication.

Enable audit logging to capture all data access.

Why wrong: Audit logging captures access but does not prevent DBAs from viewing data.

Enable encryption at rest using a customer-managed KMS key.

Why wrong: Encryption at rest protects data on disk but does not prevent DBAs from querying data through the database engine.

Disable query logging to prevent sensitive data from being written to logs.

Why wrong: Disabling logs does not prevent DBAs from accessing data directly.

Ensure the DB cluster parameter group is the same in both regions.

Why wrong: Parameter groups can be different; replication does not require them to be identical.

Create a cross-Region read replica in the secondary region.

Why wrong: Aurora does not support cross-Region read replicas; instead, you create a cross-Region Aurora replica.

The 'kms:ViaService' condition requires the request to come from RDS, but the application is making KMS API calls directly.

Why wrong: The decryption of RDS databases is done by RDS on behalf of the application, so the call to KMS comes from RDS, satisfying the condition.

The policy has a missing 'Effect': 'Deny' statement that is blocking access.

Why wrong: There is no explicit deny; the issue is that the role is not authorized.

The condition 'kms:ViaService' restricts the key to be used only with RDS, but the application is using a different service.

Why wrong: The application is using RDS, so this condition should be satisfied.

Use RDS event subscriptions to send database audit logs to an S3 bucket.

Why wrong: Event subscriptions send database events (e.g., failover, backup) not audit logs.

Configure AWS DMS to continuously replicate the audit database to an S3 bucket.

Why wrong: DMS is designed for data migration, not for capturing audit logs.

Enable RDS Enhanced Monitoring and configure it to send logs to CloudWatch Logs.

Why wrong: Enhanced Monitoring provides OS metrics, not SQL Server Audit logs.

Modify the security group to allow inbound traffic on port 5432 only from the public IP address of the application server. Rotate the password using the AWS CLI and store the new password in an encrypted file on the application server. Update the application to read the password from the encrypted file.

Why wrong: Option D is incorrect because using public IP is less secure and less reliable than private IP, and the password management is not best practice.

Modify the security group to allow inbound traffic on port 5432 only from the private IP address of the application server. Rotate the master password by modifying the DB instance and store the new password in AWS Systems Manager Parameter Store as a SecureString. Update the application to retrieve the password from Parameter Store.

Why wrong: Option B is plausible but not the best practice because Parameter Store does not support automatic rotation of RDS credentials; manual rotation is error-prone and may require downtime.

Modify the security group to allow inbound traffic on port 5432 only from the private IP address of the application server. Rotate the password using the AWS CLI and store the new password in an encrypted file on the application server. Update the application to read the password from the encrypted file.

Why wrong: Option C is flawed because storing the password in a file, even encrypted, is not as secure as a managed service and manual rotation can lead to downtime.

Enable Oracle native network encryption (NNE) in the sqlnet.ora file.

Why wrong: Option B is incorrect: RDS for Oracle does not support Oracle native network encryption; SSL/TLS is used instead.

Use AWS Secrets Manager to store database credentials and enable Kerberos authentication.

Why wrong: Option E is incorrect: Kerberos is for authentication, not encryption. AWS Secrets Manager manages secrets but does not enforce encryption in transit.

Use AWS Direct Connect or a VPN to connect to the VPC.

Why wrong: Option C is incorrect: VPN or Direct Connect secures the network layer but does not enforce encryption at the database connection level.

The KMS key ARN in the resource field is incorrect.

Why wrong: Option A is incorrect: The ARN format appears correct.

The policy is missing an encryption context that matches the secret's encryption context.

Why wrong: Option C is incorrect: The policy does not specify an encryption context, so the condition is not based on it.

The policy only allows Decrypt, but the application needs Encrypt permission.

Why wrong: Option D is incorrect: The application needs Decrypt, not Encrypt.

Enable Performance Insights on the source cluster and export the data to S3.

Why wrong: Option C is incorrect: Performance Insights is for performance monitoring, not audit logging.

Create an Aurora MySQL read replica and enable audit logs on the replica, then migrate from the replica.

Why wrong: Option D is incorrect: This does not capture audit logs from the source database.

Use AWS CloudTrail to capture SQL queries and deliver them to S3.

Why wrong: Option A is incorrect: CloudTrail does not capture database audit logs; it captures AWS API calls.