CCNA Data Security and Governance Questions

This is correct. To enforce encrypted connections for RDS MySQL, you must modify the DB parameter group to require SSL/TLS by setting parameters such as 'require_secure_transport' to 1. While the exact parameter name may vary, the intent is to enforce encryption in transit.

SSE-KMS objects require both S3 authorisation and KMS decrypt permission, since S3 calls KMS on the reader's behalf. The bucket policy grants object access; the key policy grants kms:Decrypt to the auditor's account, enabling read-only access.

A Redshift cluster's encryption key is fixed at creation time; you cannot swap the KMS key on an existing cluster. Creating a new cluster and specifying the customer-managed KMS key is therefore the required configuration step.

A bucket policy denying s3:GetObject when aws:SecureTransport is false blocks any read request that does not use TLS. This ensures the Glue job cannot read data insecurely and will fail if it attempts a non-TLS connection, satisfying the requirement for encryption in transit on reads.

AWS CloudTrail records S3 data-plane API calls such as GetObject and PutObject, capturing the identity, source IP and timestamp of each access. This satisfies the audit requirement by providing an analysable event trail for compliance, complementing S3 server access logs.

GuardDuty S3 Protection continuously analyzes CloudTrail data and management events to identify anomalous or suspicious S3 access, such as unusual API calls or access from unexpected locations. It surfaces findings that help the security team detect behavior changes rather than only recording raw events. Used alongside CloudTrail data events, it covers both the audit record and the anomaly detection requirement.

The key policy is the primary access control for a KMS key. Granting the Glue service role only kms:Decrypt and kms:GenerateDataKey, with encryption context conditions that match the bucket ARNs, enforces least privilege and ensures the key can only be used for the intended S3 data. This directly satisfies the auditable, least-privilege requirement for the Glue job.

KMS key policies are the primary way to control access to customer managed keys. Even if the IAM role has permissions in its identity-based policy, the key policy must also grant access. For a Glue job to use a KMS key, the key policy must explicitly allow the IAM role to perform kms:Decrypt and kms:Encrypt. Without this, the job will fail with access denied.

S3 object tags supply the resource-side attributes that ABAC evaluates, letting bucket policies and IAM permissions grant or deny access based on classification tags such as data sensitivity. Combined with IAM, tags form the attribute pair required for tag-based, granular object access control.

The Glue job's IAM role must have s3:GetObject and s3:PutObject permissions to read and write objects in the S3 bucket. These permissions allow the job to perform the necessary S3 operations. Without them, the job cannot access the bucket regardless of KMS permissions. Together with KMS permissions, they enable full access to the encrypted data.

The `logs:DescribeLogGroups` action permits listing and viewing log groups, while `logs:GetLogEvents` retrieves individual log events from a specified log group. Together they satisfy both stated requirements: viewing CloudWatch Logs log groups and streaming log events from the specific log group named in the stem.

The `s3:x-amz-server-side-encryption` condition key inspects the `x-amz-server-side-encryption` request header, letting the bucket policy deny any PutObject lacking a server-side encryption algorithm. This directly enforces the stem's requirement that unencrypted uploads be automatically rejected, since requests without that header fail the condition.

SSE-KMS encrypts objects at rest using keys held in AWS KMS, and the customer controls those keys through key policies and grants. This satisfies the requirement for server-side encryption with a customer-managed KMS key on the S3 bucket.

Enabling CloudTrail log file validation generates a digest file for each log, letting you verify integrity via the AWS CLI. This satisfies the tamper-proof constraint: any modification or deletion of delivered log files is detectable through hash comparison, though it does not itself prevent deletion.

AWS Lake Formation provides fine-grained access control, including column-level permissions, on Data Catalog tables. By registering the S3 location with Lake Formation and defining column-level grants, the engineer can restrict access to the PII column for specific principals. This meets the requirement without altering the data and is the recommended approach for column-level security in Glue Data Catalog.

Cross-account access requires permissions on both the S3 bucket policy and the KMS key policy. The bucket policy alone grants object access, but decryption fails because the KMS key policy does not authorise the other account's principals to call kms:Decrypt on that customer-managed key.

The KMS key policy must explicitly allow the Glue job's IAM role to perform kms:Decrypt and kms:GenerateDataKey. Even if the IAM policy on the role grants these actions, the key policy is the primary access control for KMS keys and must also grant them. Without this, the Glue job will receive an AccessDenied error when attempting to read the encrypted S3 objects.

A DynamicFrame map transformation applies a user-defined function to each record, allowing the job to rewrite only the account number column while leaving other columns untouched. This gives precise control over the masking logic, such as keeping the last four digits. It runs natively inside the Glue job and produces the required masked output.

Lake Formation data filters support both row filter expressions and column inclusion or exclusion. A filter with region='EU' limits visible rows, excluding customer_id hides that column, and granting SELECT with the filter enforces both restrictions for Athena queries. This directly matches the stated row and column requirements.

Cancelling the scheduled deletion via the KMS console or API immediately halts the pending deletion window, satisfying the stem's requirement to prevent the key from being destroyed. AWS KMS permits cancellation at any point during the mandatory waiting period, restoring the key to a usable state before permanent deletion occurs.

The policy's Action element includes wildcard permissions such as "s3:*" across all resources, so the attached user can perform any S3 operation on every bucket in the account. This exceeds the task's requirement, directly breaching the least-privilege constraint by granting far broader access than necessary.

Correct. The Glue service role must have kms:Decrypt and kms:Encrypt permissions for the KMS key to read/write encrypted data from S3.

Lake Formation data filters restrict column visibility at the catalog level, so Athena queries referencing the excluded column fail while all other columns remain readable. Granting SELECT with the filter attached enforces the restriction centrally without duplicating tables or rewriting queries, which is the least-overhead method for column-level governance.

The Glue job's execution role must have explicit permissions to use the KMS key for both reading (kms:Decrypt) and writing (kms:GenerateDataKey) encrypted objects. Without these permissions, the job cannot decrypt source data or encrypt output. This is the minimum required step to enable access while adhering to least privilege.

AWS CloudTrail records every API call to AWS services as an event, capturing the caller identity, timestamp, source IP and request details, then delivering logs to Amazon S3 for retention. This directly satisfies the compliance audit requirement to capture and store all API activity across the account.

HTTPS endpoints encrypt traffic using TLS between the EC2 instance and S3, directly satisfying the in-transit encryption requirement. AWS supports HTTPS for all S3 API operations, so requests to the REST endpoint are secured without extra configuration. This protects data crossing the network, unlike at-rest options such as SSE-KMS.

Uploading with a customer-managed KMS key requires kms:GenerateDataKey to obtain a data key for envelope encryption. s3:PutObject alone is insufficient; without that KMS permission, the request fails with AccessDenied even though the S3 action is allowed.

Adding an `aws:SourceVpc` condition to the KMS key policy restricts key usage to requests originating from the specified VPC endpoint, satisfying the requirement that the key only be usable from within the company's VPC. This condition evaluates the VPC ID of the source, blocking access from outside the VPC.

S3 bucket policies are resource-based and evaluate the bucket owner's permissions, so they grant cross-account principals access without sharing long-lived IAM credentials. This satisfies least privilege by scoping access to specific buckets or prefixes, and by letting the data lake owner retain control over who may read or write.

SSE-KMS with customer managed keys allows the company to create and manage KMS keys. AWS KMS supports automatic annual rotation of customer managed keys, which aligns with the security policy. This solution provides the required control over key management and rotation, and it encrypts data at rest in S3 using KMS keys.

AWS Config can monitor S3 bucket ACLs and policies for changes, evaluate them against desired configurations, and trigger automatic remediation using AWS Systems Manager Automation documents. This provides continuous detection and enforcement, aligning with the requirement to detect and remediate unauthorized changes.

To read an encrypted object from S3, the Lambda function needs s3:GetObject permission on the object and kms:Decrypt permission on the KMS key used to encrypt the object. Without kms:Decrypt, S3 cannot decrypt the object for the caller. This combination follows least privilege by granting only the necessary actions for reading the specific data.

By attaching an IAM policy that denies S3 actions when aws:SecureTransport is false, any request made over HTTP (non-TLS) will be denied. This enforces TLS for all S3 access, including from AWS Glue. This is a best practice for ensuring encryption in transit. The Glue job will then only be able to access S3 over HTTPS, meeting the security requirement.

HTTPS (SSL/TLS) encrypts data between the client and S3 endpoints, directly satisfying the in-transit encryption requirement. Server-side encryption options such as SSE-S3 or SSE-KMS protect data at rest only, leaving network traffic exposed. Enforcing TLS via bucket policies that deny non-secure transport further guarantees this.

The lifecycle rule transitions objects to Glacier Instant Retrieval at day 30, meeting the cost requirement, and expires them at day 2555, which equals seven years. Both the transition and retention constraints in the stem are satisfied by this single rule.

A bucket policy granting the partner account's IAM role read access satisfies the cross-account, credential-free requirement: the partner's principals assume their own roles, and AWS evaluates the resource-based policy, so no secret keys or authentication in the engineer's account are needed.

AWS CloudTrail records KMS API calls such as Encrypt, Decrypt and GenerateDataKey, capturing the identity, timestamp and key involved. This gives the 90-day audit trail of key usage events needed to verify compliance, which KMS alone does not provide.

S3 access to KMS-encrypted objects requires permissions on both the bucket policy and the KMS key policy. Because the key is customer-managed, its key policy must explicitly grant the target account's IAM role kms:Decrypt; otherwise KMS denies the request despite correct IAM and bucket configuration.

A per-file SHA-256 checksum recorded alongside the Glue job run ID gives both provenance and tamper evidence. Recomputing checksums and comparing them with the stored manifest detects any byte-level change to a curated file, and the run ID ties each file to the job execution that produced it, which is exactly what the governance team requires.

Lake Formation data filters support both row-level filter expressions and column inclusion or exclusion in a single grant. Granting SELECT with the data filter applies the row predicate and hides the excluded column for that principal, which is exactly the granular control the scenario requires without duplicating tables.

The `aws:SourceVpce` condition key restricts access to requests arriving through a named VPC endpoint, satisfying the requirement that the partner reach the bucket only via their specific endpoint. Because it evaluates the endpoint ID itself, requests from any other endpoint or the public internet are denied, even if the partner's IAM permissions allow S3 access.

SSE-S3 encrypts objects at rest using AES-256, with Amazon S3 managing the key material and rotation automatically. This satisfies the stem's data-at-rest protection requirement without the company provisioning or maintaining keys in AWS KMS, removing key-management overhead entirely.

Granting DESCRIBE and SELECT on the sales database and tables lets analysts discover and query that data without altering it, since ALTER and DROP are separate permissions not granted. CREATE_TABLE on a dedicated scratch database allows them to build temporary tables without touching the sales database. This least-privilege combination satisfies both query access and safe self-service while keeping marketing data inaccessible.

A bucket policy with the `aws:PrincipalTag` condition key evaluates the tag attached to the calling principal's identity, so only users tagged `Department: DataEngineering` satisfy the condition and gain access. This directly enforces the stem's tag-based restriction at the resource, without relying on group membership or role naming.

Sharing an encrypted RDS snapshot requires the target account to decrypt it, so the KMS key policy must grant that account kms:Decrypt and kms:CreateGrant. Without this key-policy change, the shared snapshot cannot be restored, because the target account lacks permission to use the customer-managed key.

When Glue writes data to S3 using SSE-KMS, the service must call AWS KMS to generate a data key and encrypt it. The Glue job role needs kms:Encrypt and kms:GenerateDataKey permissions on the customer-managed KMS key. Without these, the write operation fails with access denied. These permissions allow the job to encrypt the data key and use it for SSE-KMS.

The require_ssl parameter in a Redshift parameter group enforces SSL for all connections to the cluster. When set to true, clients that do not use SSL are rejected. This is the standard cluster-level setting for meeting encryption-in-transit requirements, and it applies to connections from outside the VPC as well as inside, ensuring consistent enforcement.

Lake Formation provides table-level grants within a database, so granting SELECT on the single table lets the user query it while other tables remain inaccessible. Athena alone cannot enforce such granular per-table restrictions through IAM policies.

Using a VPC connection for the Glue job and creating VPC endpoints for Kinesis and S3 ensures that traffic goes through the endpoints. Endpoint policies can enforce TLS by denying requests where aws:SecureTransport is false. This meets the requirement for TLS and use of VPC endpoints.

Lambda functions assume an IAM role that provides temporary credentials automatically. The AWS SDKs use TLS by default for all service communications, including Kinesis and S3. This setup meets the requirements for temporary credentials and encryption in transit. No additional configuration is needed for TLS; it is enforced by the SDK endpoints.

SCPs are the only AWS Organizations policy type that sets permission guardrails inherited by every member account, centrally restricting what principals can do. Applied at the organisation or OU level, they satisfy the requirement for one policy set governing all accounts.

A bucket policy with a Deny effect explicitly overrides any Allow granted elsewhere, including IAM policies, so unauthorised principals are blocked regardless of other permissions. This directly satisfies the requirement to prevent access by unauthorised users.

AWS Secrets Manager stores and rotates RDS credentials natively, with built-in rotation via Lambda and fine-grained IAM and KMS encryption. It satisfies the requirement to securely store database credentials rather than embedding them in code or configuration files.

AWS Lake Formation enforces column-level security and data masking through its permissions model, filtering PII columns for non-owner users at query time. This satisfies the requirement that PII be masked for users who are not data owners, without duplicating data or altering the underlying S3 objects.

SSE-KMS decryption requires two independent grants: the caller's identity policy must allow kms:Decrypt (and typically kms:DescribeKey), and the KMS key policy must permit that principal to use the key. The bucket policy alone only authorizes the S3 object read. Because the key lives in the producer account, its key policy must explicitly trust the analytics account role, otherwise KMS denies the data key unwrap and S3 returns AccessDenied.

Adding a bucket policy that names the other account's IAM role as principal grants cross-account access directly, satisfying the requirement to share the S3 dataset without extra infrastructure. S3 evaluates the resource-based policy against the requesting role, so no role switching, trust policy, or intermediate service is needed — the simplest mechanism available.

Lambda assumes an execution role and receives temporary credentials through the environment, so no static keys are stored. Scoping the policy to the prefix and adding a bucket policy that allows access only through the specified VPC endpoint enforces least privilege and ensures traffic stays on the private path.

AWS CloudTrail records S3 data events such as GetObject and PutObject, capturing the identity, source IP and timestamp of each API call. Enabling data-event logging on the buckets satisfies the audit requirement, which S3 server access logs alone cannot match for API-level detail.

Configuring Redshift with a hardware security module directly satisfies the CloudHSM key-storage mandate, since Redshift supports HSM connections for at-rest encryption via CloudHSM. This keeps keys inside the dedicated HSM rather than AWS-managed KMS, meeting the policy's explicit key custody constraint.

The bucket policy lacks a Deny statement with the `s3:PutObject` action and a `StringNotEquals` condition on `s3:x-amz-server-side-encryption` (and the KMS key ARN), so uploads without the customer-managed key are never refused. Without an explicit deny, S3 permits unencrypted or default-encrypted writes despite the policy.

AWS CloudTrail logs all API activity, including KMS operations such as Decrypt, Encrypt, and GenerateDataKey. By enabling CloudTrail, the engineer can capture and review these calls for auditing. CloudTrail is the standard service for auditing API activity across AWS services.

The Principal element names the AWS account permitted to read objects, directly satisfying the cross-account restriction. Bucket policies evaluate Principal against the requesting identity, so specifying the trusted account's ARN grants access solely to its users, excluding all other accounts.

AWS CloudTrail records API activity in the account, including S3 management and, with data events, object-level calls. It logs the identity, time and source of each request, providing the API audit trail the company requires.

AWS CloudTrail captures all KMS API calls as events, including the identity of the caller, time, and key ID. These events can be delivered to an S3 bucket and also to CloudWatch Logs. By creating metric filters and CloudWatch alarms, you can alert on unauthorized usage patterns. This provides both auditing and alerting, meeting the requirements.

Lake Formation grants table-level SELECT, but Athena still requires underlying AWS Lake Formation and KMS permissions for encrypted data. Without kms:Decrypt on the SSE-KMS key, Athena cannot read the encrypted objects, producing AccessDeniedException. The stem specifies SSE-KMS encryption, so the missing KMS decrypt permission is the most likely cause.

An EventBridge rule matching Macie findings can trigger a Lambda function that calls Lake Formation APIs to restrict columns or attach LF-Tags. This automates the response so newly detected sensitive columns receive restrictive permissions without manual review, satisfying the automatic restriction requirement.

The policy pairs bucket-level `s3:ListBucket` with object-level `s3:GetObject`, mapping each action to the correct ARN: `arn:aws:s3:::data-lake` for the bucket itself and `arn:aws:s3:::data-lake/*` for its objects. This satisfies the read-only requirement, since listing needs bucket scope while retrieval needs object scope.

Amazon Redshift supports encryption at rest with AWS KMS customer managed keys. When creating or modifying a cluster, you can choose a customer managed key. Separately, in AWS KMS, you can enable automatic rotation for that key with a custom period, such as 365 days. This meets both the encryption and rotation requirements. The key rotation is a property of the KMS key, not the Redshift cluster.

SSE-KMS with a customer-managed key encrypts S3 objects at rest under your own key policy, satisfying the customer-managed requirement. CloudTrail captures every KMS API call, including Decrypt and GenerateDataKey, delivering the auditable key-access trail the security team demands. SSE-S3 cannot provide either control.

S3 Batch Operations applies a single job across millions of objects, performing a copy-in-place that rewrites each object under the specified KMS key. This remediates existing objects at scale without custom scripts or per-object API calls, meeting the requirement that all objects use the customer-managed key.

Lake Formation permissions govern only requests routed through Lake Formation; direct S3 GETs are authorised by IAM. Removing IAM policies that permit s3:GetObject on the data location closes that bypass, so the user's only viable path to the data is via Lake Formation's credential vending.

The bucket policy requires a tag, and the role must have a matching condition.

EMR security configurations enable in-transit encryption using TLS for inter-node communication, plus encryption of data within the cluster. This satisfies the requirement to encrypt data moving between EMR cluster nodes, which at-rest encryption and Kerberos alone do not provide.