SOA-C02 Networking and Content Delivery Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Increase the stickiness duration to 7 days and test again

  Why it's wrong here

  Increasing the stickiness duration only changes the idle timeout for the AWSALB cookie, not whether the cookie is issued or honored. If stickiness is disabled or misconfigured at the target group level, extending the timeout to 7 days will not force the load balancer to pin sessions to a single target. Verification requires confirming that the cookie is actually present and consistent across requests, not altering its expiration period.

• ✗

  Check the ALB access logs for the presence of the stickiness cookie

  Why it's wrong here

  ALB access logs record the request headers, including the AWSALB cookie, only for subsequent requests that the client sends; they do not capture the initial Set-Cookie response header that establishes the cookie. Additionally, access logging must be explicitly enabled and delivered to a configured S3 bucket, and log delivery typically has a few minutes of latency. While logs can indicate cookie usage, they provide only indirect server-side evidence, whereas inspecting the client directly shows whether the cookie was accepted and stored.

• ✓

  Use a browser's developer tools to inspect the cookies on the client side and verify the AWSALB cookie is being set and includes the correct target group identifier

  Why this is correct

  Using a browser's developer tools directly exposes the client-side cookie jar, allowing you to confirm the presence of the AWSALB or AWSALBCORS cookie and its value, which encodes the target group identifier. You can also inspect the Network tab to see the Set-Cookie header on the initial response and verify that subsequent requests include the same cookie value. This provides definitive, real-time evidence that sticky sessions are functioning, because the cookie is the mechanism that the ALB uses to pin a session to a specific target.

• ✗

  Check the target group health check settings to ensure all instances are healthy

  Why it's wrong here

  Target group health check settings only determine which instances are eligible to receive traffic; they have no bearing on whether the load balancer is honoring the stickiness cookie to route requests to the same target. Even if all targets are healthy, requests may still be distributed across multiple instances when session stickiness is disabled or the cookie is absent from the client. Checking health confirms availability but cannot verify the stickiness behavior, which is a separate routing attribute.

Go deeper

Related to this question