CCNP Security 300-745 SDSI Practice Test 14

Correct Answer: Containers are frequently created, destroyed, and rescheduled across hosts, causing their IP addresses to change dynamically, so policy tied to static IPs quickly becomes stale or incorrect
Explanation: Containers are dynamically created, destroyed, and rescheduled, causing IPs to change and making static IP-based rules stale, unlike assuming containers keep a permanently fixed IP, that they can't use IP networking, that static rules are more accurate for containers than VMs, that containers never need segmentation, or that static rules auto-update on rescheduling.

Correct Answer: Identity-based segmentation using labels, service identities, or workload attributes rather than static IP addresses, so policy remains accurate as containers are rescheduled
Explanation: Identity/label-based segmentation remains accurate despite IP changes from rescheduling, unlike segmentation tied to a creation-time IP, disabling segmentation for dynamic workloads, segmenting by physical rack location, requiring manual permanent static IP assignment, or assuming frequent rescheduling means no segmentation is needed.

Correct Answer: Serverless functions are typically short-lived and may not have a persistent network identity to attach traditional network policy to, so segmentation must often rely on identity, API authorization, and execution-role scoping rather than network-layer rules alone
Explanation: Because serverless functions are short-lived with no persistent network identity, segmentation must rely on identity/API authorization/execution-role scoping rather than network rules alone, unlike assuming serverless functions have a persistent identity like containers, that the provider handles all security, that container network rules apply unmodified, that functions never communicate externally, or that segmentation is irrelevant due to complete isolation.

Correct Answer: A compromise of any single container could potentially reach a wide range of other workloads within the cluster, since the coarse policy would not restrict communication between unrelated services
Explanation: A coarse cluster-wide policy fails to restrict communication between unrelated services, letting a single compromise reach a wide range of workloads, unlike assuming coarse policy is stronger than granular policy, that DNS infrastructure fails, that coarse policy prevents compromise entirely, that it reduces compute consumption, or that it has no lateral movement impact.

Correct Answer: Whether the workload maintains a stable, addressable network presence suited to network-layer policy (such as a long-running container) or is ephemeral and identity-centric (such as a serverless function) better suited to identity/API-layer controls
Explanation: Whether a workload has a stable addressable network presence versus being ephemeral and identity-centric drives the network-layer-versus-identity/API-layer choice, which is unrelated to the dashboard's color scheme, platform team's coffee brand, headquarters parking space count, an internal newsletter's font, or outdoor temperature.

Correct Answer: Identity- and label-based network policy for containers that accounts for dynamic rescheduling, and identity/API-authorization-based controls for serverless functions where traditional network policy constructs do not directly apply
Explanation: Identity/label-based policy for containers (accounting for rescheduling) and identity/API-authorization controls for serverless functions together provide effective mixed-environment segmentation, unlike static IP rules for both, assuming serverless functions have persistent network identity, identity-based segmentation only for serverless, a single coarse cluster-wide policy, or disabling serverless segmentation entirely.

Correct Answer: Verify that the segmentation policy is correctly bound to the container's identity or label rather than a static IP address that would have changed during rescheduling
Explanation: Verifying the policy is bound to identity/labels rather than a static IP that changed on rescheduling is the appropriate diagnostic step, unlike blaming desktop wallpaper, disabling all cluster enforcement, wrongly assuming rescheduling is deprecated, blaming unrelated host air conditioning, or blaming the phase of the moon.

Correct Answer: Container and serverless workloads are ephemeral and frequently change their network location, so policy bound to a stable identity attribute (such as a label or service identity) remains accurate, while policy bound to a static IP quickly becomes outdated
Explanation: Because ephemeral workloads change network location frequently, identity-bound policy stays accurate while IP-bound policy becomes outdated, unlike claiming the two approaches are identical, that static IP segmentation is always more accurate, that this is guest-only, that static rules auto-adapt to rescheduling, or that identity-based segmentation eliminates network connectivity needs.

Correct Answer: Continuously rediscovering workload dependencies as new containers and functions are deployed, ensuring segmentation policy remains identity-based rather than reverting to static IP assumptions, and periodically validating policy accuracy against actual observed traffic
Explanation: Continuous dependency rediscovery, maintaining identity-based (not static-IP) policy, and periodic validation against observed traffic together sustain effective segmentation as the architecture evolves, unlike a set-once policy, assuming new workloads auto-inherit accurate policy, reverting to static IP rules, annual-only review, or disabling rediscovery once initially segmented.

Correct Answer: Applying least-privilege IAM role scoping specific to that function's actual required permissions, rather than reusing a broad, shared execution role across many unrelated functions
Explanation: Least-privilege IAM role scoping specific to each function's actual needs prevents excessive access, unlike assigning a shared broad administrative role, disabling IAM enforcement, assuming the provider auto-scopes permissions correctly, granting unrestricted default access, or requiring manual per-execution approval with no role automation.