CCNA Db Security Questions

IAM database authentication allows an IAM user to authenticate to an RDS MySQL database using an IAM user or role. The IAM policy must include the rds-db:connect action with a resource ARN specifying the RDS instance and the database user name. When the resource ARN includes 'db_user1', the policy only permits connection as that specific database user, not as any user.

Option A is incorrect because the policy does not grant permissions to any database or any user; it is scoped to 'db_user1'. Option B is incorrect because the rds-db:connect action does not grant management of the RDS instance. Option D is incorrect because the resource ARN restricts to 'db_user1', so connecting with any other database user name would be denied.

Options A and B are correct. Creating an IAM role for the Lambda function with permissions to use RDS IAM database authentication (A) avoids hardcoding credentials and enables secure, temporary authentication. Placing the Lambda function in the same VPC as the RDS instance (B) ensures traffic stays within the AWS network without traversing the internet.

Option C is wrong because storing credentials in Lambda environment variables is insecure and exposes them. Option D is wrong because using the database master user account violates least privilege and is insecure. Option E is wrong because a NAT gateway is not needed for RDS access within the same VPC.

You cannot modify the encryption key of an existing DynamoDB table. To switch to a customer-managed KMS key without downtime, you must create a new table with the desired key, export data from the old table using AWS Data Pipeline, and import into the new table. Option A is incorrect because the UpdateTable API does not support changing the KMS key after table creation.

Option B is incorrect because DynamoDB Streams and Lambda are not suitable for full table migration, especially for global tables. Option C is incorrect because replicas inherit the table's encryption key and cannot have a different key.

An IAM policy with a condition key `rds:StorageEncrypted` set to `true` can deny the `rds:CreateDBInstance` action when encryption is not enabled, enforcing encryption at rest at creation time. Option B is wrong because CloudTrail is an auditing service; it logs API calls but cannot automatically delete unencrypted instances without additional services like Lambda. Option C is wrong because AWS Config detects and reports noncompliant resources but does not prevent creation; it is reactive.

Option D is wrong because Amazon RDS does not offer a default encryption setting at the account level; encryption must be explicitly enabled per instance.

Amazon GuardDuty with RDS Protection provides real-time monitoring of database activity on Amazon RDS instances, analyzing SQL queries and detecting suspicious behavior such as SQL injection or unusual access patterns. Option A (AWS CloudTrail) is incorrect because it records API calls made to the AWS environment, not the database queries themselves. Option B (AWS Security Hub) is incorrect as it aggregates security findings from multiple AWS services but does not perform real-time database activity monitoring.

Option D (Amazon Inspector) is incorrect because it is a vulnerability assessment service that scans for software vulnerabilities and unintended network exposure, not for database query threats.

Options A and B are correct. VPC security groups control network access to the RDS instance at the instance level, acting as a virtual firewall. IAM policies can control who can perform administrative actions on the RDS instance via the AWS API, such as creating, modifying, or deleting the instance.

Option C is incorrect because CloudWatch alarms monitor performance metrics and trigger actions, but do not control access. Option D is incorrect because database passwords are a form of authentication for users connecting to the database, not a method to control access to the RDS instance itself. Option E is incorrect because S3 bucket policies control access to Amazon S3 resources, not RDS.

The best practice is to use dedicated database users with minimal privileges for each application function (Option A). This principle of least privilege limits the damage a SQL injection attack can cause because the compromised user cannot perform unauthorized actions beyond its specific scope. Option B is incorrect because the 'sql_mode' parameter can reject certain dangerous queries but does not address the root cause of excessive privileges and may not prevent all injection attacks.

Option C is incorrect because audit logs only help detect incidents after they occur, not prevent them. Option D is incorrect because while placing the RDS instance in a private subnet and restricting inbound traffic reduces the network attack surface, it does not prevent SQL injection attacks that originate from the application itself; the vulnerability lies in how the application interacts with the database.

To encrypt RDS snapshots with a customer-managed KMS key, you must first take a snapshot of the existing instance (which uses an AWS-managed key). Then, copy that snapshot and specify the customer-managed KMS key during the copy operation. Finally, restore from the copied snapshot to create a new instance encrypted with the customer-managed key.

Option A is incorrect because you cannot change the encryption key of an existing instance; you must copy the snapshot. Option B is correct and describes the proper procedure. Option C is incorrect because the default KMS key for the account does not affect existing instance snapshots.

Option D is incorrect because you cannot modify an existing RDS instance to use a different encryption key directly; the encryption key is set at creation.

Enabling encryption at rest using AWS KMS is a straightforward way to meet the encryption-at-rest requirement for RDS. Option B: Configuring a security group to allow inbound traffic from the specific CIDR range restricts network access to the database. Option C is incorrect because encryption in transit is handled by the database engine (e.g., SSL/TLS) and is not an RDS option group feature; you enable it on the client side or by modifying the DB parameter group.

Option D is incorrect because DB parameter groups do not control network access; they manage database engine parameters. Option E is incorrect because AWS KMS is the default service for RDS encryption at rest; CloudHSM is an alternative for key management but not required.

Automated backups with encryption at rest ensure that backups are automatically taken daily and encrypted. Option C is correct because it enables both features: automated backups and encryption at rest. Option A is incorrect because manual snapshots are not automatic; they require manual intervention and enabling encryption on the snapshot copy is an extra step.

Option B is incorrect because using CloudWatch Events and Lambda to export to S3 is not the standard automated backup mechanism for RDS; RDS automated backups are handled natively and do not require custom Lambda functions. Option D is incorrect because AWS Backup is not the default automated backup service for RDS; RDS has its own automated backup feature. Additionally, encryption for RDS backups is managed by AWS KMS, not S3 default encryption.

To encrypt data in transit, you need to enforce SSL on the server side and ensure the client uses SSL. Setting the 'require_secure_transport' parameter to 'ON' in the DB cluster parameter group (Option C) forces the server to require SSL connections. Configuring the application connection string to use the SSL-enabled endpoint (Option D) ensures the client connects using SSL.

Option A is unnecessary because Aurora supports SSL natively without a load balancer. Option B does not encrypt traffic; a VPN only secures the network path but does not enforce encryption at the database layer. Option E encrypts data at rest, not in transit.

DynamoDB Global Secondary Indexes (GSIs) have their own Amazon Resource Names (ARNs) separate from the base table. When using IAM policies with fine-grained access control, the policy must explicitly include the ARN of the GSI in the resource statement to allow operations like Scan on that GSI. Without the GSI ARN, the Scan operation on the GSI is denied by default, even if the policy allows 'dynamodb:Scan' on the base table.

Option A is incorrect because the policy does not mention time-of-day conditions. Option B is incorrect because the role can read from the base table, but the issue is with the GSI. Option D is incorrect because the action 'dynamodb:Scan' is allowed on the table but not on the GSI.

Enabling the rds.force_ssl parameter in the DB parameter group forces all connections to use SSL, satisfying the encryption-in-transit requirement. The application must be configured to connect using SSL with the appropriate certificate. Option A is wrong because changing the security group to port 443 does not enforce encryption; port 443 is for HTTPS, not for Oracle database traffic, and SSL is configured at the database level.

Option C is wrong because the default parameter group does not enforce SSL; the rds.force_ssl parameter must be explicitly set. Option D is wrong because a VPN adds unnecessary complexity and does not directly enforce TLS encryption for database connections.

Enabling 'require_secure_transport' in the MySQL parameter group forces the server to accept only SSL/TLS connections. Applications that are not configured with SSL will be rejected, causing them to fail after this change. Option A is incorrect because the security group inbound rule missing would have prevented connections entirely, not just after this change.

Option B is incorrect because the SSL option in the option group is separate from the 'require_secure_transport' parameter; the parameter group controls this setting. Option D is incorrect because the DB subnet group determines network placement, not SSL enforcement.

The IAM policy includes two Allow statements. The first statement grants rds:DescribeDBInstances only on a specific DB instance ARN in us-east-1. The second statement grants the same action on any resource (*).

Because IAM evaluates the effective permissions as the union of all statements, the user is only allowed to describe that specific instance in us-east-1; describing instances in any other region (such as us-west-2) is not explicitly allowed for that resource, so the request is denied. Option D is correct because it acknowledges that the resource ARN restriction from the first statement limits the allowed region. Option A is incorrect because there is no MFA condition in the policy.

Option B is incorrect because the user can describe the specific instance in us-east-1. Option C is incorrect because the policy restricts access via a resource ARN, not a condition key.

Amazon RDS Enhanced Monitoring requires the IAM role to have permission to describe the DB instance using 'rds:DescribeDBInstances'. This action is necessary for the monitoring service to retrieve information about the instance so it can collect and publish OS metrics. If the policy explicitly denies this action, Enhanced Monitoring will fail to display metrics.

Option C is incorrect because 'monitoring:ListMetrics' is not required; Enhanced Monitoring publishes to CloudWatch Logs, not CloudWatch Metrics, and the IAM role needs logs permissions (e.g., 'logs:PutLogEvents') rather than monitoring actions. Options B and D are also incorrect: 'rds:CreateDBInstance' is unrelated to monitoring, and using a resource of '*' is acceptable as long as the trust policy allows RDS to assume the role.

The correct method to enable encryption for future backups on an existing unencrypted Amazon RDS for PostgreSQL instance is to create a snapshot of the DB instance, copy the snapshot with encryption enabled, and restore the encrypted snapshot to a new DB instance. Option A is incorrect because there is no 'backup_encryption' parameter in the DB parameter group. Option B is incorrect because modifying the DB instance does not allow enabling encryption on an unencrypted instance; encryption can only be enabled at creation time.

Option C is incorrect because enabling encryption on the S3 bucket does not encrypt the RDS backups themselves; the backups must be encrypted at the source.

You cannot directly enable encryption on an existing unencrypted Amazon RDS instance. The correct process is to create a snapshot of the DB instance, copy the snapshot with encryption enabled, and then restore the encrypted snapshot to a new DB instance. You then redirect traffic to the new instance.

Option A is incorrect because creating a read replica does not encrypt the master instance, and the replica can only be encrypted if the master is already encrypted. Option B is incorrect because you cannot modify an existing DB instance to enable encryption through the RDS console. Option D is incorrect because enabling encryption directly on the existing DB instance is not supported.

The most likely cause is that the security group for the RDS instance still contains a rule allowing inbound traffic from the public IP addresses of the EC2 instances. After disabling public accessibility, the EC2 instances in the public subnet may receive new public IPs if they are stopped and started, or the original rule may have referenced specific public IPs that are no longer valid. The application's connection attempts using the old public IPs fail.

Although the security group was updated to allow traffic from the application's security group, the old rule might not have been removed, or the application was not using the security group reference. Since the EC2 instances are in the same VPC, the private IP communication should work with the security group reference, but if the old rule is still present and the public IPs changed, the connection might fail. Options A and D are incorrect because same-VPC communication does not require VPC peering or a NAT gateway.

Option C is incorrect because the public DNS name resolves to the private IP within the VPC even after public accessibility is disabled, so it should work.

Options A and D are correct. AWS Secrets Manager provides native automated rotation for RDS credentials, while AWS Systems Manager Parameter Store (SecureString) can centrally store encrypted credentials and support automated rotation when combined with a custom AWS Lambda function. Both services allow centralized management of database credentials, and with additional configuration, both can automate rotation.

Option B (AWS KMS) is incorrect because KMS manages encryption keys, not secrets. Option C (IAM database authentication) is incorrect because it eliminates the need for stored credentials but does not centrally manage or rotate them. Option E (AWS CloudHSM) is incorrect because it provides hardware security modules for key storage, not secret management.

The correct procedure. To encrypt an existing unencrypted RDS DB instance, you must create a manual snapshot of the instance, then copy that snapshot with encryption enabled (specifying a KMS key), and finally restore a new DB instance from the encrypted snapshot. Option A is wrong because the console does not provide a direct 'Enable Encryption' action on an existing instance.

Option B is wrong because you cannot modify an existing unencrypted instance to enable encryption directly; there is no such modification parameter. Option C is wrong because while it mentions copying the snapshot to an encrypted one, it does not clarify that encryption is applied during the copy operation, and the correct process explicitly requires taking the initial snapshot, copying with encryption, and then restoring; Option D includes all three steps.

To meet the requirements, two configurations are needed. First, the DB instance must be set to not publicly accessible (Option D) to ensure it cannot be reached from the internet. Second, the security group associated with the DB instance must allow inbound traffic only from the application server's security group (Option C), which restricts access to resources within the VPC.

Option A is incorrect because placing the DB instance in a public subnet would expose it to the internet. Option B is incorrect because the DB parameter group controls database engine settings, not network access. Option E is incorrect because network ACLs are stateless and a rule denying all inbound traffic would block legitimate traffic as well; security groups are the appropriate mechanism for this scenario.

To meet both requirements, the engineer should create a customer managed KMS key, enable automatic key rotation (which rotates the key annually, but for 90-day rotation, the engineer can create a new key every 90 days and update the table), and configure CloudTrail to log data events for the DynamoDB table. CloudTrail data events capture data plane operations like GetItem and PutItem, which addresses the logging requirement. Option A is incorrect because AWS managed keys do not support automatic rotation; also, CloudTrail data events are not tied to key type.

Option B is incorrect because switching to a customer managed key alone does not enable data event logging. Option C is incorrect because DynamoDB Streams are used for change data capture and streaming to other services, not for audit logging of data plane operations; CloudWatch Logs from Streams do not capture all API calls.

An existing unencrypted Amazon RDS instance cannot be directly encrypted. The standard approach to enable encryption with minimal downtime is to create a snapshot of the DB instance, copy the snapshot with encryption enabled, and restore the snapshot to a new encrypted DB instance. This process typically involves a brief outage during the restore but is simpler than other methods.

Option B is incorrect because the AWS CLI does not support enabling encryption on an existing instance. Option C is incorrect because migrating to RDS Custom adds unnecessary complexity and does not directly enable encryption on the current instance. Option D is incorrect because the AWS Management Console also does not allow enabling encryption on an existing instance.

An IAM policy attached to a role used by an RDS instance, combined with a VPC endpoint to KMS, restricts the allowed KMS actions to only those specified and requires that the request originate from the RDS service via that specific VPC endpoint. Option A is incorrect because it suggests all KMS actions are allowed, which is not the case; only specified actions are allowed. Option B is incorrect because it mistakenly implies the policy allows actions from any source, ignoring the VPC endpoint restriction.

Option C is incorrect because it states the policy applies to all KMS keys, whereas it is typically scoped to a specific key.

To change the encryption key from Oracle TDE to AWS KMS, you must take a snapshot of the DB instance, copy the snapshot with KMS encryption, and restore from the encrypted snapshot. This process enables encryption at rest with KMS. Option B is incorrect because you cannot directly enable KMS encryption on an existing TDE instance; this is not supported.

Option C is incorrect because creating a read replica does not allow changing the encryption key; read replicas inherit the source instance's encryption. Option D is incorrect because you cannot modify the encryption key in place on an existing instance.

The IAM policy only includes the actions 'dynamodb:GetItem' and 'dynamodb:PutItem', but does not include 'dynamodb:DescribeTable'. Therefore, the IAM user is denied the DescribeTable action by default. Option A is incorrect because although action names are case-sensitive, the policy uses the correct lowercase 'dynamodb' and the actions are properly cased.

Option B is incorrect because there is no implicit Deny; the policy grants access to GetItem and PutItem, and DescribeTable is simply not allowed. Service control policies could apply, but they are not the most likely reason given the policy's explicit lack of the required action. Option D is incorrect because the resource '*' does include all tables; the problem is the missing action, not the resource specification.

Amazon RDS encryption at rest with a customer-managed KMS key can only be enabled when the DB instance is created. You cannot enable encryption on an existing unencrypted instance (option A is incorrect). Once you create a new encrypted instance using the desired KMS key, you can migrate the data from the old instance and then delete it.

Option D is incorrect because restoring a snapshot of an unencrypted database without modifying encryption settings will result in an unencrypted instance; you would need to create an encrypted copy of the snapshot first, which is not described. Option C is incorrect because DB parameter groups do not control encryption at rest.

The security requirements are to have encryption at rest and automatic annual key rotation. Amazon Redshift clusters can only be encrypted at creation time; you cannot enable encryption on an existing unencrypted cluster. Therefore, the only way to meet the requirements is to create a new encrypted cluster using a KMS key with automatic rotation enabled. The existing cluster must be replaced by restoring from an encrypted snapshot or by creating a new cluster and migrating data. Option D precisely describes this solution: 'Create a new encrypted cluster with a KMS key and configure automatic key rotation.' Automatic rotation can be enabled on the KMS key, and Redshift will use the new key material automatically for re-encryption.

Option A is ambiguous: 'Use AWS KMS with automatic key rotation to encrypt the Redshift cluster' – this could be interpreted as enabling encryption on an existing cluster, which is not possible. Option D clearly states the correct procedure. Hence D is the best answer.

Option B is wrong because CloudHSM-backed encryption does not support automatic key rotation; rotation must be done manually.

Option C is wrong because encryption cannot be enabled on an existing cluster; a new encrypted cluster must be created.