AWS SOA-C03 Free Practice Questions — Page 2

Correct Answer: D. Take a snapshot of the RDS instance, copy and encrypt the snapshot, and then restore to the new RDS instance.

Amazon RDS does not support encrypting an existing unencrypted database instance in place—encryption must be enabled at creation time. The only way to encrypt an existing unencrypted RDS instance is to take a snapshot, create an encrypted copy of that snapshot by specifying a KMS key during the copy operation, and then restore a new RDS instance from the encrypted snapshot. After verification, you can update application connection strings to point to the new encrypted instance and delete the old unencrypted one. The first option is incorrect because there is no checkbox in the RDS console to enable encryption on an already-running instance; encryption is immutable after creation. The second option is incorrect because RDS uses managed storage that you cannot directly attach EBS volumes to—RDS abstracts the underlying storage layer. The third option is incorrect because in Multi-AZ deployments, both the primary and standby replicas share the same encryption setting; you cannot have one encrypted and one unencrypted, and standby replicas cannot be independently encrypted. This process requires planning for downtime or using DNS updates to minimize disruption during the migration.

Correct Answer: C. Create a network ACL. Add an outbound deny rule for traffic to the external IP address.

Network ACLs (NACLs) are stateless firewalls that operate at the subnet level and support explicit deny rules, making them ideal for blocking specific IP addresses. To block traffic to the suspicious external IP address, create or modify the NACL associated with the subnet containing the compromised EC2 instance, and add an outbound deny rule for that specific IP address with a lower rule number (higher priority) than any allow rules. Security groups cannot be used for this purpose because they are stateful and only support allow rules—there is no deny capability in security groups, so you cannot explicitly block specific IP addresses. The first option is incorrect because security groups lack deny rules; removing an allow rule might work if traffic was explicitly allowed, but doesn't guarantee blocking if broader rules exist. The second option is incorrect because VPC Flow Logs are a monitoring and logging tool for network traffic analysis, not an enforcement mechanism—they cannot block traffic. The fourth option is incorrect because security groups are attached to individual resources (EC2 instances, network interfaces), not to entire VPCs, and again, they lack deny functionality. Additional incident response steps should include isolating the instance, capturing forensic data, and investigating the root cause.

Correct Answer: D. The target group health check is configured with an incorrect port or path.

When EC2 instances appear healthy in the Auto Scaling group but unhealthy in the ALB target group, this indicates a discrepancy between the two different health check mechanisms. Auto Scaling groups by default use EC2 system status checks (instance reachability), which only verify that the instance is running at the infrastructure level. ALB target group health checks are application-layer checks that send HTTP/HTTPS requests to a specific port and path (e.g., GET /health on port 80) and expect a successful response code (typically 200). If the target group health check is misconfigured with the wrong port, path, or expected response codes, the ALB will mark instances as unhealthy even though they are running properly from an EC2 perspective. The first option about security groups is less likely because if security groups were blocking traffic, the ALB couldn't communicate with the instances at all, but the question implies some initial connectivity. The second option describes the default Auto Scaling behavior but doesn't explain the discrepancy—it's actually the reason why they might differ. The third option is incorrect because if instances were failing EC2 status checks, they would show as unhealthy in the Auto Scaling group as well, contradicting the scenario. To resolve this, verify the target group health check settings match the application's actual listening port and health endpoint.

Correct Answer: B. Create an AWS Config rule that is invoked when CloudTrail configuration changes. Apply the AWS-ConfigureCloudTrailLogging automatic remediation action.

AWS Config provides managed rules and automatic remediation actions that can detect and correct configuration drift without custom code. The cloudtrail-enabled managed Config rule detects when CloudTrail is disabled, and the AWS-ConfigureCloudTrailLogging Systems Manager Automation document is a pre-built remediation action that automatically re-enables CloudTrail when non-compliance is detected. This solution is event-driven, responding immediately when CloudTrail configuration changes, and requires no custom code development. The first option is incorrect because simply adding the account to AWS Organizations and enabling CloudTrail in the management account doesn't prevent someone from disabling CloudTrail in the member account or automatically re-enable it if disabled. The third option would work but requires writing custom Lambda code, which violates the "without writing custom code" requirement. The fourth option is incorrect because an hourly scheduled rule introduces delays—CloudTrail could remain disabled for up to an hour before remediation occurs, and this doesn't meet the "immediately" requirement. AWS Config with automatic remediation provides real-time detection and response, making it the most appropriate solution for immediate, code-free remediation.