CCNA Security Questions

The aws:SecureTransport condition key specifically evaluates whether the incoming request to an S3 bucket was made using HTTPS (TLS/SSL). When set to "true" in a bucket policy, it mandates that all interactions with the bucket must occur over an encrypted connection, effectively preventing unencrypted HTTP requests. This directly addresses the requirement to ensure that the S3 bucket only allows secure, encrypted data transfer.

This is the correct solution as it precisely grants the necessary permissions while adhering to the principle of least privilege. Attaching a policy statement to the 'LambdaExecutionRole' is the standard method for providing a Lambda function with permissions to interact with other AWS services. The 's3:PutObject' action is the specific permission required to write objects, and 'arn:aws:s3:::my-app-bucket/*' correctly scopes this permission to all objects within the specified S3 bucket.

Creating an Origin Access Identity (OAI) and granting it read access in the S3 bucket policy is the recommended and most secure method. The OAI acts as a virtual user for your CloudFront distribution, allowing only that specific distribution to retrieve content from the S3 bucket. This prevents direct public access to the S3 bucket while enabling CloudFront to serve the content securely to end-users.

For a Lambda function to successfully write logs to CloudWatch Logs, its execution role requires specific permissions. While `logs:PutLogEvents` is necessary to transmit the actual log data, the function also crucially needs `logs:CreateLogStream` to establish a new log stream within the designated log group if one does not already exist for that particular invocation or execution environment. Without this `CreateLogStream` permission, the function cannot initialize the required logging infrastructure, leading to a failure in log delivery, even if it possesses the permission to put events.

Bucket policies are resource-based access policies directly attached to an S3 bucket, defining who (principals like IAM users, roles, or other AWS accounts) can perform which actions (e.g., GetObject, PutObject) on the objects within that specific bucket. They are fundamental for granting cross-account access, defining public access configurations, or restricting access based on IP addresses. These policies act as a primary access control layer, evaluated directly by the S3 service upon every request to the bucket.

Cognito User Pools are the identity store and authentication service in Cognito, and they include a native MFA configuration option supporting SMS text message codes or TOTP authenticator apps, which can be set to off, optional, or required per user pool, directly satisfying the requirement to add MFA.

AWS IAM policy evaluation logic dictates that an explicit Deny statement always overrides any Allow statements, regardless of where the Allow is defined (e.g., in the user's identity-based policy). If the S3 bucket policy contains an explicit Deny for the s3:ListBucket action for the specific user or a group they belong to, this Deny will take precedence and prevent the user from listing the bucket's contents, even if their IAM policy allows it.

Granting only ec2:StartInstances and ec2:StopInstances gives the IAM user exactly the actions needed to power instances on and off while omitting ec2:TerminateInstances entirely, so any attempt to terminate an instance is implicitly denied by IAM's default-deny behavior, satisfying the requirement precisely.

When an S3 object is encrypted using Server-Side Encryption with AWS KMS (SSE-KMS), the requesting principal requires explicit kms:Decrypt permissions on the associated KMS key. Even if the S3 bucket policy grants s3:GetObject to another account, the cross-account caller cannot retrieve the object's plaintext data without the necessary KMS key usage permissions. This dual authorization ensures robust data protection by separating storage access from encryption key access.

IAM policies are the core mechanism for defining fine-grained permissions. You can craft JSON-based identity policies that specify exactly which actions are allowed or denied on which resources, under what conditions (e.g., source IP, MFA presence, time of day). This allows least-privilege access control at the resource and API-action level, central to IAM's purpose.

To enable encryption, the Application Load Balancer (ALB) must be able to receive incoming encrypted traffic from clients. A security group rule allowing inbound traffic on port 443 (HTTPS) is fundamental, as it acts as a virtual firewall, explicitly permitting the necessary TLS communication to reach the ALB. Without this rule, client connections attempting to establish an encrypted session would be blocked at the network layer, preventing any encryption from occurring.

s3:GetObject is the specific action that permits downloading an object's content from S3, and it carries no ability to write, overwrite, or delete anything, making it the precise, minimal permission that satisfies a read-only access requirement for retrieving object data.

This is the correct action. To ensure a file is encrypted with Server-Side Encryption with AWS KMS (SSE-KMS) during an AWS CLI upload, the --sse aws:kms parameter must be explicitly specified. This parameter instructs S3 to use KMS for encryption. If a specific KMS key is desired, it can be combined with the --kms-key-id parameter; otherwise, S3 will use the default AWS managed key for S3 in the account.

Launching an EC2 instance with an IAM role is the AWS best practice for granting applications secure access to AWS services like S3. An IAM role provides temporary security credentials that are automatically rotated and delivered to the instance via the instance metadata service. This eliminates the need to embed or manage long-term access keys on the instance, significantly reducing the risk of credential compromise and simplifying credential management, aligning with the principle of least privilege.