CCNA Data Security and Governance Questions

Options A, D, and E are correct. To encrypt data in transit between EC2 and RDS MySQL, you need to enforce SSL/TLS connections. Option A configures the RDS instance to require SSL connections.

Option D uses a JDBC driver with useSSL=true to enforce SSL from the client side. Option E enables the rds.force_ssl parameter in the RDS parameter group to force SSL connections at the database level. Option B is incorrect because VPC peering establishes network connectivity but does not encrypt data.

Option C is incorrect because encryption at rest secures stored data, not data in transit.

The Deny statement denies s3:GetObject if the object does not have the tag 'classification' (i.e., the tag is null). Since the object has no tags, the condition evaluates to true, and the action is denied. The Allow statement only allows if the tag equals 'public', which is not the case.

The explicit Deny overrides any Allow, so access is denied.

Lake Formation column-level filtering allows granting access to specific columns in a table without granting access to the entire table. Option A (row-level security) controls access to rows, not columns. Option B (IAM policies on the S3 bucket) would grant access to the entire dataset or bucket, not specific columns.

Option D (tag-based access control) uses tags to manage permissions but does not provide column-level granularity.

Lake Formation can be used to grant SELECT permission on the database and tables, and by using column-level and row-level filters, but to hide S3 locations, the data scientist should not have direct S3 access. Lake Formation does not require the user to see the S3 path. Granting IAM read-only access to S3 would expose locations.

Using a VPC endpoint does not hide locations. Glue resource policies cannot hide S3 locations.

DMS supports SSL/TLS for encrypting connections. Option A (VPC peering) is incorrect because VPC peering does not encrypt traffic. Option B (Enable SSL encryption on the DMS endpoint) is correct because SSL/TLS encrypts the data in transit.

Option C (Set up a VPN connection) is correct because VPN creates an encrypted tunnel. Option D (Use KMS) is incorrect because KMS is for encryption at rest, not in transit. Option E (VPC endpoint) is incorrect because VPC endpoints provide private connectivity but do not encrypt transit.

AWS Trusted Advisor checks for S3 buckets with public access, helping to detect accidental public access. S3 Block Public Access can be enabled at the account or bucket level to prevent public access. AWS Config can evaluate rules but does not directly detect or prevent public access.

AWS CloudTrail records API calls but does not prevent public access. Amazon Macie discovers sensitive data, not public access.

Encryption in transit for Redshift is achieved by using SSL connections. Client-side encryption before loading does not encrypt the transmission. Server-side encryption is for at-rest.

VPC security groups control network access, not encryption.

In Amazon Redshift, to access a table, a user must have USAGE permission on the schema containing the table, in addition to SELECT or other table-level permissions. Without USAGE on the schema, the user receives a 'permission denied for relation' error even if SELECT is granted. Option D is correct.

Option A (session timeout) would cause a different error or disconnection. Option B (no CONNECT permission) would prevent connecting to the database. Option C (wrong schema) would result in a 'schema not found' error, not a permission denied error.

To encrypt data at rest in Amazon RDS for MySQL, you must enable encryption when creating the DB instance (option C). This uses an AWS KMS key (option B) to manage the encryption. Encrypted instances require that automated backups and snapshots are also encrypted (option E).

Option A (SSL/TLS) encrypts data in transit, not at rest. Option D (modifying the DB parameter group) does not enable encryption at rest.

Server-side encryption with S3 managed keys (SSE-S3) encrypts data at rest on the server side. Client-side encryption encrypts data before uploading, ensuring it is encrypted at rest from the client's perspective. Options A and E are for encryption in transit, and C is versioning, not encryption.

Correct: B and D.

The bucket policy uses a Deny effect with a condition that checks if the s3:x-amz-server-side-encryption header is not 'aws:kms'. This means any PutObject request that does not use SSE-KMS will be denied. Therefore, the policy enforces that all objects uploaded must be encrypted with SSE-KMS.

Option A is incorrect because the policy does not mention SSE-S3; it denies if not SSE-KMS. Option B is incorrect because it requires SSE-KMS, not SSE-S3. Option C is incorrect because the policy only allows SSE-KMS, not any type of server-side encryption.

Option D is correct.

AWS KMS supports automatic key rotation for customer managed keys. Option B is wrong because CloudHSM does not provide automatic rotation. Option C is wrong because Secrets Manager is for secrets.

Option D is wrong because ACM is for certificates.

S3 bucket policies can include a condition that denies PutObject requests if they do not include the required encryption headers (e.g., x-amz-server-side-encryption). This enforces encryption at rest by rejecting unencrypted uploads. Default encryption only automatically encrypts objects that are uploaded without encryption headers, but does not reject them.

MFA Delete is for requiring multi-factor authentication for delete operations, not for encryption. S3 Block Public Access controls public access to buckets, not encryption. Therefore, option A is correct.

A bucket policy granting access to the IAM role in Account B is the recommended secure method for cross-account access to S3 objects encrypted with S3-managed keys. Option A is insecure because it grants public access. Option C is incorrect because ACLs are legacy and less secure for cross-account scenarios.

Option D is incorrect because while S3 VPC endpoints are a valid AWS feature that provides private connectivity to S3, they do not grant cross-account access; bucket policies are still required to authorize access.