DVA-C02 Security 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.

• ✗

  Enable encryption on the ALB using a custom SSL certificate.

  Why it's wrong here

  Enabling encryption on the ALB using an SSL certificate establishes a secure HTTPS connection between the client and the load balancer, encrypting all data in transit. This prevents eavesdropping on the network communication. However, it does not directly influence or enforce the `Secure` or `HttpOnly` attributes of a session cookie, which are directives set by the application server for the browser's behavior, not transport layer encryption.

• ✗

  Store session data in ElastiCache instead of cookies.

  Why it's wrong here

  Storing session data in ElastiCache offloads the actual session payload from the cookie, leaving only a session identifier in the browser's cookie. This reduces the risk of sensitive data exposure if the cookie is intercepted and can improve performance by reducing request header size. Nevertheless, if the session ID itself is stolen through means like XSS, an attacker can still use it to impersonate the user, as ElastiCache only stores the data associated with that ID, not protecting the ID's integrity or confidentiality during transit or storage in the browser.

• ✓

  Set the Secure and HttpOnly flags on the session cookie.

  Why this is correct

  Setting the `Secure` flag ensures that the browser will only send the session cookie over encrypted HTTPS connections, preventing its transmission over insecure HTTP and protecting against passive network eavesdropping. The `HttpOnly` flag prevents client-side scripts, such as JavaScript, from accessing the cookie's value. This is a critical defense against Cross-Site Scripting (XSS) attacks, where an attacker might otherwise inject malicious scripts to steal session cookies and hijack user sessions.

• ✗

  Use AWS WAF to block requests without a valid session cookie.

  Why it's wrong here

  AWS WAF operates at the application layer and can inspect incoming HTTP requests, including headers and cookie values, to block malicious traffic based on predefined rules. While WAF can detect the presence or specific content of a cookie, it cannot directly enforce or modify the `Secure` or `HttpOnly` attributes of a session cookie. These attributes are directives set by the web application server for the client browser, not something WAF can manage or inject into the browser's cookie handling.