Courseiva
Security ArchitecturehardMultiple SelectObjective-mapped

SY0-701 Security Architecture Practice Question

A team is deploying a containerized API to a public cloud. The service must be reachable only by internal corporate applications, and secrets must not be embedded in images or readable as plaintext by administrators of the underlying host. Which two actions best fit the design? Select two.

⚠ Common exam trap

Test-takers frequently confuse network-level access control (public IP with allowlist) with true private connectivity, or they underestimate the risk of host administrators reading secrets from container images or environment variables, assuming that tenant isolation or encryption at rest alone is sufficient.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Place the API in a private subnet and expose it only through an internal load balancer or private endpoint.

Placing the API in a private subnet and exposing it only through an internal load balancer or private endpoint ensures that the service is reachable only by internal corporate applications, as traffic never traverses the public internet. This design leverages network segmentation and private IP addressing to enforce access control at the network layer, aligning with the requirement for internal-only reachability.

Answer analysis

Option-by-option breakdown

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

  • Place the API in a private subnet and expose it only through an internal load balancer or private endpoint.

    Why this is correct

    Private subnets and internal endpoints keep the service off the public internet while still allowing controlled access from trusted corporate systems. This reduces exposure, simplifies firewall policy, and supports the requirement that only internal applications can reach the API. It is a common secure cloud architecture pattern for internal services.

  • Give each container a public IP and restrict access by source IP allowlist.

    Why it's wrong here

    Granting each container a public IP with source IP allowlisting exposes the service to the public internet, which violates the requirement that the API be reachable only by internal corporate applications; a private cloud network or VPC with no public endpoint is needed. This option is tempting because source IP allowlisting is a common method for restricting access to a public-facing service from known corporate IP ranges, and it would be correct if the scenario permitted a publicly routable endpoint with trusted source addresses.

  • Store secrets in a managed vault and retrieve them at runtime with short-lived IAM permissions.

    Why this is correct

    Using a managed secrets vault avoids hardcoding credentials in images, source code, or environment files. Short-lived permissions reduce the value of stolen credentials and limit what an attacker can do if a token is compromised. This is the right pattern for protecting secrets from both operators and runtime exposure.

  • Bake database passwords into the container image so deployment is simpler.

    Why it's wrong here

    Embedding secrets in an image is risky because the image may be copied, cached, scanned, or retained long after deployment. Anyone with access to the image can potentially extract the password. Simplicity does not outweigh the security and lifecycle problems created by hardcoded credentials.

  • Assume the cloud provider's tenant isolation alone is enough to protect secrets from misuse.

    Why it's wrong here

    Tenant isolation protects one customer from another, but it does not solve application-level secret handling or misuse by authorized insiders. The scenario requires the secrets not be readable in plaintext from the host or image, which calls for explicit secret management and permission controls, not trust in isolation alone.

Visual reference

192.168.1.0 /24 256 addresses (254 usable) 192.168.1.0 /25 Subnet A 128 addr (126 usable) 192.168.1.128 /25 Subnet B 128 addr (126 usable) Borrowing 1 bit from host portion creates 2 subnets (/25)

About these practice questions

This SY0-701 question is part of Courseiva's 1,013-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.