CCNA Continuous Improvement Questions

A service control policy (SCP) can deny PutBucketAcl or PutBucketPolicy actions if the bucket does not have encryption enabled, preventing disabling of encryption at the bucket level. Option D is correct because AWS Config managed rule s3-bucket-server-side-encryption-enabled can detect S3 buckets that lack server-side encryption. Option E is correct because enabling default encryption on all S3 buckets ensures that new objects are automatically encrypted.

Option A is incorrect because while an S3 bucket policy can enforce encryption on uploads, it does not enforce encryption on existing objects and must be applied per bucket; moreover, it is not an organization-wide enforcement mechanism. Option C is incorrect because AWS CloudTrail only logs API calls and does not enforce encryption; it can alert but does not remediate.

AWS CodePipeline with a source stage from CodeCommit, a build stage using CodeBuild, and a deploy stage that syncs to S3 and invalidates CloudFront provides a fully managed CI/CD pipeline with minimal operational overhead. Option A is wrong because CloudFormation is for infrastructure provisioning, not for building a deployment pipeline triggered by code pushes. Option B is wrong because S3 event notifications trigger Lambda functions for simple tasks, not for full CI/CD build and deploy workflows.

Option D is wrong because Lambda@Edge is for processing requests at edge locations, not for building and deploying static content.

The output shows the instance has a security group 'sg-web-app' attached to its network interface. If that security group allows inbound traffic from 0.0.0.0/0, the instance would be accessible from the internet regardless of the subnet being private. The subnet's route table (Option A) having a route to an internet gateway would not matter for inbound traffic because the instance is in a private subnet and lacks a public IP; the ALB would handle inbound traffic via its public IP and forward to the private instance.

Option B is incorrect because an Elastic IP would make the instance directly reachable from the internet, but the output does not show an Elastic IP. Option C is incorrect because the instance is in a private subnet and would not have a public IP assigned automatically.

Enabling default encryption on the S3 bucket using SSE-S3 or SSE-KMS ensures that all objects are automatically encrypted at rest, regardless of whether the upload request specifies encryption. This is the simplest and most effective approach. Option A is technically viable but unnecessarily complex; a bucket policy that denies uploads without the x-amz-server-side-encryption header can enforce encryption, but it requires careful policy configuration and does not encrypt objects automatically if the header is missing—instead it rejects the upload.

Option B is inefficient and costly; using a Lambda function to encrypt objects after upload introduces latency and extra expense, whereas default encryption achieves the same result seamlessly. Option C is incorrect because S3 Access Points are designed for managing access to shared datasets, not for enforcing encryption; adding a policy there would complicate access management without providing the automatic encryption that default encryption offers.

AWS CloudFormation Change Sets allow you to preview how proposed changes will affect your running resources before executing them. By using Change Sets in conjunction with a manual approval process (e.g., via AWS CodePipeline or a separate review step), you can ensure changes are reviewed and approved before being applied. Option A (termination protection) only prevents stack deletion, not updates.

Option B (auto-deployment with CodePipeline) can include approval gates, but the question asks for the "BEST way" in the context of CloudFormation itself; Change Sets are the native mechanism for review. Option D (stack policies) control which resources can be updated, but do not enforce a review process.

Adding more EC2 instances behind a load balancer allows you to distribute the workload across multiple smaller instances, which can be more cost-effective than a single large instance. This approach (scaling out) can improve performance and availability without necessarily increasing costs, as you can use smaller, cheaper instance types. Option B is wrong because rightsizing to a larger instance typically increases cost, contrary to the goal of cost optimization.

Option C is wrong because purchasing a Reserved Instance reduces cost but does not address the high CPU utilization performance issue. Option D is wrong because launching a new instance of the same type does not solve the performance problem.

Adding an HTTPS listener to the ALB with an ACM certificate and configuring the HTTP listener to redirect to HTTPS ensures all traffic is encrypted in transit. This meets the security requirement directly without additional components. Option A is incorrect because Network Load Balancers do not support ACM certificates for TLS termination; they require TLS termination on the backend instances.

Option B is incorrect because TCP listeners cannot terminate TLS, and self-signed certificates on EC2 instances would not provide trusted encryption for clients. Option C is incorrect because while CloudFront can provide HTTPS, it adds unnecessary complexity and cost; the requirement can be met natively with the ALB.

If the security group for the tasks does not allow inbound traffic from the ALB on the health check port, health checks fail and tasks cannot register. Option B is incorrect because a desired count of zero would prevent new tasks from running, but the scenario describes deployments failing due to health check failures on new tasks. Option C is incorrect: an invalid container image would cause the task to fail to start, not cause health check failures after the task is running.

Option D is incorrect because Fargate manages capacity; insufficient capacity would cause a different error (e.g., unable to provision tasks), not health check failures.

CloudFront's built-in geo-restriction feature allows whitelisting or blacklisting countries. Option C is correct because AWS WAF geo match conditions can be used with a CloudFront distribution to block or allow requests based on country codes. Option D is correct because CloudFront geographic restriction is another name for the same feature as geo-restriction, and it is a valid action.

Option A is incorrect because S3 bucket policies do not support geographic location conditions; they only support IP-based conditions. Option E is incorrect: although Lambda@Edge can be used to check the country and return a 403, it is not one of the simplest recommended actions; the question asks for actions the company can take, and geo-restriction and WAF are the primary methods.

Lifecycle rules for noncurrent versions do not automatically expire delete markers. Delete markers are not considered noncurrent versions and require a separate ExpiredObjectDeleteMarker action in the lifecycle policy. Option B is incorrect because bucket policies do not affect lifecycle expiration.

Option C is incorrect because versioning must be enabled for noncurrent version expiration to work; if versioning were disabled, the lifecycle rule would not apply. Option D is incorrect because the lifecycle rule is enabled as per the template; the issue is the absence of a rule for delete markers.

Increasing the number of DPUs (data processing units) allocated to the Glue job allows for greater parallelism, which directly reduces processing time for CPU-bound or memory-bound workloads. Option A is incorrect because increasing the timeout does not improve performance; it only prevents the job from failing due to time limits. Option B is incorrect because S3 Transfer Acceleration speeds up data transfer to S3, not the processing within Glue.

Option D is incorrect because while converting to Parquet can improve read performance and reduce data volume, it does not address the core processing bottleneck if the job is compute-intensive; the most effective immediate step is to increase DPUs.

Updating the CloudFormation stack directly with a new DBInstanceClass property will cause a reboot of the RDS DB instance, which typically has minimal downtime compared to creating a new instance. This is the standard approach for modifying RDS instance classes. Option A is incorrect because AutoScalingReplacingUpdate is an update policy for Auto Scaling groups, not applicable to RDS DB instances.

Option B is incorrect because creating a new stack and deleting the old one would cause significant downtime and is not efficient. Option D is incorrect because AWS OpsWorks is not used for managing RDS instances.

The most efficient way to alert when an IAM user creates a new access key is to use CloudWatch Events (now Amazon EventBridge) to match the CreateAccessKey API call from CloudTrail and trigger an SNS notification. Option A is incorrect because CloudTrail Insights is for detecting unusual activity patterns, not for real-time event-driven alerts. Option C is less efficient because it requires additional steps of publishing logs to CloudWatch Logs and creating a metric filter, adding complexity.

Option D is inefficient because querying CloudTrail logs with Athena is not real-time and requires custom scheduling.

To delete a subnet that is in use by a Lambda function's ENI, you must first disassociate the ENI. This can be done by updating the Lambda function configuration to remove the VPC settings, which causes Lambda to delete the ENI. After the ENI is deleted, you can delete the subnet.

Option B is incorrect because the DeletionPolicy attribute only handles deletion, not update failures, and the subnet is still in use. Option C is incorrect because there is no force delete option for subnets; dependencies must be resolved first. Option D is incorrect because ENIs managed by Lambda cannot be manually deleted; you must update or delete the Lambda function.

It leverages the existing CodePipeline CI/CD system with a built-in approval gate, allowing the operations team to review and approve CloudFormation stack updates before deployment with minimal additional overhead. Option A (Change Sets) requires manual execution and lacks integration with the CI/CD pipeline. Option B (Lambda + SNS) introduces custom code and additional management overhead.

Option C (Service Catalog) is designed for provisioning new resources, not for change management of existing stacks. Option D (manual CLI + peer review) does not automate the process and increases operational overhead.

Increasing read capacity units (RCUs) directly increases the number of read operations per second, reducing latency during peak hours. Option C is correct because DynamoDB Accelerator (DAX) is an in-memory cache that significantly reduces read latency by caching frequently accessed items. Option E, adding a Global Secondary Index (GSI), can improve query performance but not necessarily overall read latency for existing access patterns; it is a design change that may not address peak-hour latency directly.

Option A is incorrect because global tables are for multi-region replication, not single-region performance. Option D is incorrect because changing the sort key does not improve read performance; sort key affects ordering within a partition, not throughput.

It combines DynamoDB auto scaling to adjust capacity during traffic spikes with retry logic and exponential backoff in the Lambda function to handle transient ProvisionedThroughputExceededException errors gracefully without losing requests. Option B is wrong because fixing capacity to a high value is costly and inefficient; it doesn't adapt to variable traffic. Option C is wrong because using an SQS queue between API Gateway and Lambda would buffer requests but does not directly address the DynamoDB throughput exception; it would only shift the problem.

Option D is wrong because API Gateway cannot automatically retry failed requests; retries must be implemented in the backend.

Options C and D are correct. A target tracking scaling policy (C) automatically adjusts capacity based on a specified metric like CPU utilization, providing dynamic scaling for unpredictable spikes. A simple scaling policy with a step adjustment (D) allows you to define specific thresholds (e.g., CPU > 80%) to add instances quickly.

Option A is wrong because a lifecycle hook delays termination during scale-in, which would increase costs by keeping instances running longer. Option B is wrong because manually adjusting capacity is not automated and does not respond quickly to spikes. Option E is wrong because scheduled scaling is for predictable patterns, not unpredictable traffic spikes.

If the deployment removed the health check path from the application, the health checks would fail for any instance that was updated. Since the application runs behind an ALB, the target group health check would mark those instances as unhealthy, causing intermittent 503 errors as traffic is routed only to remaining healthy instances. Even if not all instances are updated simultaneously, the gradual roll-out could lead to periods where all instances become unhealthy temporarily.

Option A is incorrect because a low idle timeout would cause timeout errors, not 503s. Option B is incorrect because security groups were not changed. Option C is incorrect because misconfigured health check settings would cause consistent failures, not intermittent.

A Change Set allows you to preview the changes that will be made during a stack update, including any potential errors or resource conflicts, before executing the update. This helps identify the specific resource causing the failure. Option B is wrong because the Events tab shows past events but does not provide a preview of planned changes or conflicts.

Option C is wrong because StackSets are used for deploying stacks across multiple accounts and regions, not for troubleshooting a single stack update. Option D is wrong because drift detection compares the current stack resources with the template to identify manual changes, not update conflicts.

The 'AccessDenied' error despite having the StopInstances permission indicates that something else is denying the action. The most likely cause is a service control policy (SCP) attached at the account or organizational level, or a resource-based policy on the EC2 instance itself that explicitly denies the action. Option A is wrong because incorrect CLI syntax would cause a different error.

Option B is wrong because the policy may not have a tag-based condition; the issue is not about missing tag permissions. Option C is wrong because the policy can use a wildcard for the Resource field, so not specifying an instance ID does not cause AccessDenied. Option D correctly identifies that an SCP or resource-based policy is denying the action.

The most secure way to enforce SSE-KMS across all S3 buckets is to use an S3 bucket policy that denies PutObject if the required encryption header is not present. This ensures that any upload attempts without SSE-KMS are rejected, providing a preventive control. Option A is incorrect because AWS Config rules can only detect and remediate after the fact, not prevent non-compliant uploads.

Option B is incorrect because default encryption can be overridden by specifying a different encryption header in the request. Option C is incorrect because IAM policies control permissions for API calls but cannot enforce specific encryption parameters on object uploads.

A target tracking scaling policy dynamically adjusts the number of instances based on average CPU utilization, which addresses intermittent CPU spikes. The Auto Scaling group also automatically replaces instances that fail ALB health checks, ensuring unhealthy instances are replaced. This optimizes costs by scaling down during low usage.

Option B is incorrect: lifecycle hooks are for custom actions during instance launch or termination, not for replacing unhealthy instances. Option C is incorrect: terminating instances with high CPU via Lambda does not integrate with Auto Scaling and could cause instability. Option D is incorrect: scheduled scaling is for predictable traffic patterns, not intermittent spikes.

The key policy shown does not contain any explicit deny statements, so the inability to decrypt must be due to an explicit deny elsewhere in the key policy (possibly not shown) or in an IAM policy attached to the role. Option B is incorrect because the kms:CallerAccount condition checks the AWS account ID of the principal making the request; when a role from account 123456789012 is assumed, the caller account is 123456789012, regardless of the user's origin. Therefore, the condition would pass, and the first statement would apply.

Since both statements allow decryption, the only remaining explanation is an explicit deny somewhere.

AWS DMS with ongoing replication (change data capture) can achieve sub-5-second RPO by continuously replicating changes to a target database in another Region. The RTO can be under 1 minute if the target is pre-provisioned and promotion is automated. Option C: A cross-Region read replica uses asynchronous replication, but when configured for maximum throughput, the typical lag is under 5 seconds, and promoting the replica takes less than a minute, meeting the RPO and RTO requirements.

Options B is incorrect because Multi-AZ deployments are limited to a single Region and do not support cross-Region synchronous replication. Option D: Daily snapshots have an RPO of up to 24 hours. Option E: Automated backups have an RPO of up to 5 minutes and an RTO longer than 1 minute.

Therefore, only A and C satisfy the required RPO and RTO.

Amazon RDS Proxy manages connection pooling between Lambda functions and RDS, reducing the overhead of opening and closing connections, which helps avoid latency and timeouts during peak load. Option A is incorrect because DAX is a caching layer for DynamoDB, not RDS. Option B is incorrect because while Read Replicas can offload read traffic, they do not address connection management, and Lambda still creates many connections.

Option C is incorrect because increasing instance size is vertical scaling and does not solve the connection pooling issue; it may still lead to timeouts under high connection surges.

An S3 bucket policy with a condition that denies PutObject if the x-amz-server-side-encryption header is not present enforces encryption for all new objects. Option A is wrong because Amazon CloudFront enforces HTTPS for data in transit, not server-side encryption at rest. Option B is wrong because enabling S3 default encryption encrypts objects that do not specify encryption, but it does not deny uploads without encryption headers; objects can still be uploaded without explicitly setting encryption.

Option C is wrong because pre-signed URLs provide temporary access but do not enforce encryption requirements.

Increasing the reserved concurrency for the Lambda function guarantees that the function can process more invocations concurrently, reducing throttling errors. Option A is incorrect because SQS queues do not have a configurable concurrency limit; concurrency is managed at the Lambda function level. Option C is incorrect because distributing messages across multiple queues does not increase the function's concurrency; each queue invocation still counts toward the same reserved concurrency.

Option D, increasing the batch size, can improve throughput per invocation but does not reduce throttling caused by insufficient concurrency.

The most likely cause of the timeout is that the Lambda function is attached to a VPC but does not have a NAT gateway or VPC endpoints to access external resources (Option D). When a Lambda function is configured to run in a VPC, it loses default internet access. To access external services (such as an external database or API), the function needs a NAT gateway in a public subnet or VPC endpoints for the specific services.

Without this, the function will timeout when trying to reach external resources. Option A is incorrect because cold starts cause latency but not consistent timeouts. Option B is incorrect because hitting the concurrent execution limit would cause throttling (HTTP 429 or 500 errors), not timeouts.

Option C is incorrect because attaching to a public subnet would not help; Lambda functions cannot have public IPs in a VPC by default, and a public subnet does not provide internet access without an internet gateway and route table updates.

The most appropriate solution is to create one or more RDS read replicas and direct read queries to the replica endpoint. Read replicas offload read traffic from the primary Multi-AZ instance, improving read latency with minimal application changes (only the read endpoint needs to be updated). Option A (DynamoDB Global Tables) would require a complete database migration and application rewrite, which is not minimal.

Option C (ElastiCache) would require application code changes to cache queries, and may not be as effective for complex joins. Option D (increasing instance size) is vertical scaling that may only provide limited improvement and does not directly address read-heavy workloads; it also incurs higher cost without truly scaling out read capacity.

Modifying the StorageType property of an RDS DB instance (e.g., from gp2 to io1) can be done without replacing the resource. When the CloudFormation stack is updated with this change, AWS performs an in-place modification that typically causes only a brief downtime (a few minutes). This is the standard approach to minimize downtime.

Option B is incorrect because UpdateReplacePolicy is not a valid CloudFormation attribute; the correct attribute is UpdatePolicy, but it does not apply to RDS storage type changes. Option C is incorrect because creating a new stack and migrating data would cause significantly more downtime and effort. Option D is incorrect because DeletionPolicy controls what happens when a resource is deleted from the stack, not during an update.

High request count per target with low CPU utilization suggests the application is I/O bound or waiting on external calls. Adding more instances by increasing the desired capacity distributes the load across more targets, reducing queueing and improving performance. Option A is wrong because the bottleneck is not CPU, so increasing instance size is unlikely to help.

Option C is wrong because scaling based on CPU utilization would not trigger since CPU is low. Option D is wrong because changing the ALB routing algorithm to least outstanding requests might help distribute load more evenly but does not add capacity; increasing desired capacity directly addresses the high request count per target.

Enabling default encryption on each S3 bucket ensures that all objects uploaded to that bucket are automatically encrypted, enforcing the policy across existing and future buckets. Option B is wrong because an IAM policy that denies s3:PutObject without encryption headers only applies when the request includes encryption headers; it does not enforce encryption for all objects, and it depends on the caller including the headers. Option C is wrong because while an S3 bucket policy can deny PutObject without encryption, it requires a policy per bucket and does not automatically remediate existing buckets.

Option D is wrong because AWS Config can detect noncompliant buckets but requires a custom remediation action to enable encryption; it does not automatically enforce encryption without additional setup.

S3 Standard provides immediate access for the first 90 days, and then transitioning to S3 Glacier Deep Archive (retrieval time up to 12 hours) meets the 7-year retention requirement at the lowest cost. Option A is wrong: while S3 Glacier can also provide retrieval within 12 hours (via its Bulk retrieval option), S3 Glacier Deep Archive is more cost-effective for long-term archival with comparable retrieval times. Option B is wrong: S3 One Zone-Infrequent Access is not durable enough for compliance (single Availability Zone) and deleting after 90 days does not satisfy the 7-year retention requirement.

Option D is wrong: S3 Standard-Infrequent Access is for infrequent access but transitioning to S3 Standard is more expensive, and the lifecycle policy does not achieve the 7-year retention.

Upgrading to a larger instance type with higher IOPS directly increases the I/O capacity of the RDS instance, improving write performance without requiring application changes. Option A is incorrect because read replicas are used to offload read traffic, not to improve write latency. Option C is incorrect because Multi-AZ deployment provides high availability and automatic failover, but does not directly improve write performance.

Option D is incorrect because modifying DB parameter groups can tune certain database settings but does not increase the underlying IOPS provided by the instance type.

The most likely cause is that the subnet's network ACL is blocking inbound SSH traffic. While the security group allows SSH from anywhere (0.0.0.0/0), network ACLs operate at the subnet level and can override security group rules. If the network ACL denies inbound traffic on port 22, SSH connections will be blocked.

Option A is less likely because even without a public IP, the instance could be reached via private IP from within the VPC; the scenario implies external SSH access. Option B is incorrect because system status checks indicate underlying hardware issues, not connectivity problems. Option C is incorrect because the security group is attached by default when launching an instance, and the question confirms it allows SSH.

Amazon RDS Proxy provides connection pooling, allowing the application to reuse existing connections rather than opening new ones. This reduces the number of simultaneous connections to the database, alleviating CPU and connection limit pressure. It requires minimal code changes.

Option A is incorrect because migrating to Aurora does not address the connection management problem; it may still require RDS Proxy. Option B is incorrect because increasing max_connections does not fix the root cause of unclosed connections and can lead to resource contention. Option C is incorrect because scaling the application tier horizontally would increase the number of connections, worsening the issue.