Database Security practice questions

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: Creating a cross-region read replica is the outcome of enabling cross-region replication, not a separate required step. When you enable cross-region replication on the Aurora cluster in the primary region, Aurora automatically creates and maintains a cross-region read replica in the secondary region.

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: Ly uses the public IP address of the application server, which is insecure for internal traffic. Storing the password in an encrypted file on the application server still leaves it at rest on the server and does not follow AWS best practices for centralized secrets management with automatic rotation.

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: This option fails because AWS Systems Manager Parameter Store SecureString does not support native automatic rotation for RDS master passwords. While it stores the password securely, the lack of rotation means the password remains static unless manually rotated, which does not meet the requirement for password management best practices.

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: Ly stores the password in an encrypted file on the application server instead of using a centralized secret management service like Secrets Manager. It does not provide automatic rotation or eliminate the risk of password exposure at rest on the server.

Configure RDS to publish audit logs directly to an S3 bucket with a bucket policy that restricts access to the security team's IAM roles.

Why wrong: Amazon RDS does not support publishing audit logs directly to an S3 bucket. Audit logs must be sent to CloudWatch Logs or other destinations first.

Install a custom audit plugin on the RDS instance that writes logs to a separate RDS table, then use AWS Lambda to export the table to S3 periodically.

Why wrong: While a custom audit plugin could write logs to a table, exporting to S3 via AWS Lambda adds significant complexity and operational overhead compared to the native CloudWatch integration.

Enable RDS audit logs and send them to Amazon Kinesis Data Firehose, which writes to an S3 bucket with encryption and VPC endpoint restrictions.

Why wrong: Amazon RDS cannot directly send audit logs to Kinesis Data Firehose. You would need additional components (e.g., Lambda) to forward logs from CloudWatch to Firehose, increasing complexity and overhead.

Create a backup of the table, restore the backup to a new table, and specify the customer-managed key during restoration.

Why wrong: While backup/restore allows specifying a new KMS key on the restored table, this approach is less efficient because it requires creating a full backup first. AWS Glue can copy data directly without an intermediate backup.

Use the AWS Management Console to modify the table and select the customer-managed key.

Why wrong: The AWS Management Console cannot change encryption on an existing DynamoDB table; encryption is set only at table creation.

Use the AWS CLI 'update-table' command with the --sse-specification parameter to change the key.

Why wrong: The 'update-table' command with --sse-specification cannot alter encryption on an existing table; encryption is immutable after creation.

Send KMS audit logs to Amazon CloudWatch Logs.

Why wrong: CloudTrail already logs; CloudWatch Logs is for monitoring, not enabling audit.

Enable AWS Config to record KMS key configuration changes.

Why wrong: Config records resource changes, not API usage.

Enable VPC Flow Logs for the DynamoDB VPC endpoint.

Why wrong: VPC Flow Logs capture network traffic, not KMS usage.

Use Oracle Data Pump to export the data, encrypt it using CloudHSM, and import it back into RDS.

Why wrong: Oracle Data Pump is for data import/export, not for transparent encryption at rest. It does not meet the requirement of transparent encryption.

Enable TDE and configure the Oracle wallet to point to the CloudHSM key.

Why wrong: While Oracle TDE can use an external HSM via the Oracle wallet, RDS does not provide the necessary access to configure the wallet to point to CloudHSM.

Enable TDE and use AWS KMS as the key manager by integrating with the Oracle TDE keystore.

Why wrong: AWS KMS can be used as the key manager for Oracle TDE in RDS, but it does not support keys stored in CloudHSM. KMS custom key stores are not compatible with RDS Oracle TDE.

Implement row-level security policies using CREATE ROW LEVEL SECURITY POLICY.

Why wrong: Row-level security policies (e.g., in PostgreSQL) are not available in Redshift.

Use GRANT SELECT ON table (col1, col2) TO user.

Why wrong: Although Redshift does support column-level GRANT (e.g., GRANT SELECT ON table (col1) TO user), creating views is the more standard and manageable approach for column-level access control.

Encrypt the sensitive columns using AWS KMS and decrypt in the application.

Why wrong: Column-level encryption with AWS KMS does not provide fine-grained access control; it only protects data at rest and requires application changes for decryption.

Modify the DB instance and set the encryption attribute to true.

Why wrong: RDS does not support enabling encryption on an existing instance via modification.

Use AWS Database Migration Service (DMS) to migrate the data to a new encrypted RDS instance.

Why wrong: This is possible but less efficient than the snapshot approach.

Create a read replica with encryption enabled and promote it to become the primary instance.

Why wrong: Read replicas of unencrypted instances cannot be encrypted.

Enhanced Monitoring

Why wrong: Enhanced Monitoring provides metrics on OS processes, not database audit logs.

VPC Flow Logs

Why wrong: VPC Flow Logs capture IP traffic information, not database queries.

AWS CloudTrail

Why wrong: CloudTrail records API calls, not database-level events.

Enable AWS CloudTrail for the RDS instance.

Why wrong: CloudTrail does not capture database-level events.

Modify the security group to log all inbound traffic on port 5432.

Why wrong: Security groups do not provide logging.

Enable RDS Enhanced Monitoring.

Why wrong: Enhanced Monitoring does not log database connections.

Use IAM database authentication for Aurora and eliminate the use of database passwords.

Why wrong: Incorrect. IAM database authentication eliminates the need for passwords but does not automatically rotate credentials or prevent hardcoding; it still requires a way to authenticate as the IAM role.

Use AWS Systems Manager Parameter Store to store the credentials and grant access via IAM roles.

Why wrong: Incorrect. AWS Systems Manager Parameter Store can store credentials and control access via IAM roles, but it does not support automatic rotation for RDS credentials.

Store the credentials in an encrypted S3 bucket and grant access to the microservices via bucket policies.

Why wrong: Incorrect. Storing credentials in an encrypted S3 bucket does not provide automatic rotation and is less secure for secrets management compared to dedicated services like Secrets Manager.

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, so allowing inbound port 3306 from the EC2 instance’s private IP would also require a corresponding outbound rule for ephemeral ports to permit return traffic, which the existing configuration does not specify. This option is tempting because network ACLs can filter traffic at the subnet boundary, and in a scenario where the RDS instance lacked a security group or required subnet-level restrictions, modifying the ACL would be a valid additional layer. However, the security group attached to the RDS instance already controls inbound access, and the correct approach is to replace the overly permissive 0.0.0.0/0 rule with a rule referencing the EC2 instance’s security group, which is stateful and automatically handles return traffic.

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.