Important Amazon SOA-C03 Exam Questions

Answer: C

Explanation:

Instances in private subnets do not have direct routes to an internet gateway, so they cannot reach public internet endpoints unless the VPC provides a managed egress path. The standard AWS architecture for private-subnet outbound internet access is to use a NAT device (typically a NAT gateway) placed in a public subnet, with an Elastic IP address and a route from the private subnet to that NAT gateway for 0.0.0.0/0 traffic. The NAT gateway then forwards traffic to the internet through the VPC's internet gateway while preventing unsolicited inbound connections to the private instances.

The scenario states that the VPC has a NAT gateway in each private subnet. That placement prevents proper egress because a NAT gateway itself must be in a public subnet with a route to the internet gateway to function for internet-bound traffic. Without that, private instances will fail to reach external services such as a third-party API, exactly as observed.

Option C corrects the architecture by deploying NAT gateways in the public subnets with Elastic IPs and updating the private subnet route tables so that outbound internet traffic targets the NAT gateways. This enables private workloads to initiate outbound connections while remaining unreachable from the public internet directly, maintaining the intended security posture.

Option A is incorrect because an outbound-only internet gateway is designed for IPv6 egress, not IPv4 internet access. Option B misunderstands routing: API Gateway is an application-layer proxy service and is not a target for VPC route tables to provide generic internet access. Option D is not applicable because VPC interface endpoints provide private connectivity to supported AWS services via PrivateLink, not to arbitrary external public APIs.

Therefore, deploying NAT gateways in the public subnets and routing private subnet egress through them is the correct solution.

Answer: A

Explanation:

AWS CloudOps automation best practices recommend using AWS Systems Manager Quick Setup for organization-wide management and configuration of EC2 instances. The Default Host Management Configuration Quick Setup automatically enables Systems Manager capabilities such as Patch Manager, Inventory, Session Manager, and Automation across all managed instances within the organization.

When deployed from the management account, Quick Setup automatically integrates with AWS Organizations to propagate configuration and permissions to existing and future accounts. This meets the requirement for organization-wide management with no manual configuration or SSH access. AWS documentation notes:

''You can use Quick Setup in the management account of an organization in AWS Organizations to configure Systems Manager capabilities for all accounts and Regions. Quick Setup automatically keeps configurations up to date.''

Options B, C, and D require custom deployments or manual IAM updates, lacking centralized automation. Therefore, Option A fully satisfies CloudOps standards for automated provisioning and ongoing management of EC2 instances across an organization.

Answer: A

Explanation:

The most secure solution is to remove the hardcoded password completely and let AWS Secrets Manager generate, store, and rotate the database password. The AWS::SecretsManager::Secret resource with GenerateSecretString avoids exposing a static password in templates, parameters, source control, or deployment logs. The AWS::SecretsManager::RotationSchedule resource automates the required 90-day password rotation. The application should retrieve the secret at runtime from Secrets Manager by using an IAM role with least-privilege access. Option B still accepts a human-provided password, which is weaker than automatic secret generation. Parameter Store can store secure values, but it does not provide the same native database credential rotation workflow as Secrets Manager. NoEcho only masks console output; it does not make user data or template handling sufficiently secure.

Answer: B

Explanation:

Because S3 Versioning is enabled, each object update creates additional object versions. If old versions are never removed, storage costs keep increasing even when only the latest version is needed operationally. The lowest-overhead solution is to configure an S3 Lifecycle rule to expire noncurrent object versions after the required 90-day compliance retention period. This preserves object changes for the required window and then automatically removes older versions to reduce cost. Option A is not ideal because creating delete markers affects current object visibility and does not clean up old noncurrent versions efficiently. Option C adds unnecessary backup complexity. Option D creates excessive event scheduling and Lambda management overhead. S3 Lifecycle is the native cost-optimization control for versioned-object retention.

Answer: C

Explanation:

The symptom of users seeing old versions for several days points directly to CloudFront caching. If the file is updated daily but the object key remains the same, CloudFront edge locations may continue serving the cached object until the TTL expires. Setting cache TTL values to 0 forces CloudFront to revalidate with the origin instead of serving stale content for long periods. This is the best option from the choices because it resolves delayed visibility of new versions. Removing S3 lifecycle rules does not affect CloudFront cache freshness. Updating the behavior path pattern does not solve stale object delivery if the cache behavior already applies. Extending the signed URL expiration only solves authorization timing; it does not force CloudFront to fetch the latest object version. For production, versioned object names or invalidations would also be strong designs.