CompTIA Updated SY0-701 Exam Questions and Answers by alfie-james

In the context of the CompTIA Security+ SY0-701 exam, orchestration is the most appropriate answer because it directly aligns with the automation of repetitive, operational security tasks. Orchestration refers to the coordinated execution of automated processes to streamline workflows, reduce administrative burden, and ensure consistent outcomes. Creating a script to automate user account creation for a large number of users is a textbook example of orchestration in action.

The Security+ SY0-701 study guide emphasizes that automation and orchestration are essential components of modern security operations. They are used to minimize human error, improve efficiency, and enforce consistency across environments. Manual account creation is error-prone, especially at scale, and can lead to misconfigured permissions, inconsistent group memberships, or skipped security steps. Orchestration ensures that predefined steps—such as creating user accounts, assigning roles, applying access controls, enforcing password policies, and logging actions—are executed reliably every time.

The other options do not fit the scenario. Off-the-shelf software refers to prebuilt commercial solutions rather than a custom script. A baseline defines a standard configuration state but does not automate actions. Policy enforcement ensures compliance with rules but does not perform the operational task itself. The key distinction is that orchestration focuses on execution and coordination of tasks, not governance or standards.

From a Security+ operational standpoint, orchestration supports secure identity and access management by ensuring accounts are provisioned consistently and in alignment with organizational policies. It also improves auditability and accountability by enabling predictable, repeatable processes. Therefore, orchestration is the correct and most secure solution for automating large-scale account creation.

A diagram of a computer AI-generated content may be incorrect.

Step 1: Understand Requirements & Security Principles

Requirements:

Customer-facing payment application (PCI DSS compliance applies)

Hosted on third-party cloud (e.g., AWS)

Must segment public-facing and internal resources

Needs to be scalable and resilient

Must have strong security controls

Step 2: Design the High-Level Network Layout

Core Components:

VPC (Virtual Private Cloud): Isolates your environment from other tenants in the cloud.

Subnets:

Public subnet: For resources that must communicate with the internet.

Private subnet: For internal resources, NOT directly exposed to the internet.

Step 3: Place Resources in Appropriate Subnets

Public Subnet:

Internet-facing Load Balancer (LB): Distributes traffic to application servers.

Web Application Firewall (WAF): Protects against web exploits.

Autoscaling Instances: EC2 (or VM) servers running your web front-end, automatically scaling as traffic grows.

Private Subnet:

Application servers: Back-end logic, not exposed to internet directly.

Database: Sensitive data storage, only accessible by application servers.

Internal Load Balancer: Manages traffic among app servers.

WAF: Can be used internally as well for defense-in-depth.

Step 4: Add Connectivity and Security Controls

Internet Gateway: Allows resources in public subnet to communicate with the internet.

NAT Gateway: Allows outbound internet traffic from private subnet without exposing private IPs.

Security Groups: Firewalls at the instance level; allow only necessary traffic (e.g., LB to web server, web server to DB).

Network ACLs: Subnet-level firewalls for additional control.

Step 5: Network Diagram Explanation (Based on Your Images)

Public Subnet (Top Layer)

Load Balancer

Accepts HTTPS traffic from customers.

Sends only necessary HTTP/HTTPS to web servers in public subnet.

WAF (Web Application Firewall)

Sits in front of Load Balancer.

Filters malicious requests (SQLi, XSS, etc.).

Autoscaling Group

Multiple web servers for redundancy and scalability.

Placed in public subnet to respond to traffic spikes.

Private Subnet (Bottom Layer)

Application Servers

Receive requests from public subnet’s load balancer.

Not directly exposed to the internet.

Database

Only accessible from application servers, never public.

Security groups restrict all inbound traffic except from app servers.

Internal Load Balancer

Balances requests to application servers.

Step 6: Flow of Data (Step-by-Step)

Client - > Internet Gateway - > WAF - > Load Balancer (Public Subnet):Customers initiate connections to your app over the internet.

Load Balancer - > Autoscaling Web Servers (Public Subnet):Load balancer routes requests to available web servers.

Web Servers - > Application Logic (Private Subnet):Web servers pass necessary requests to the internal application servers.

App Servers - > Database (Private Subnet):Application servers query/update customer payment data in the database.

Outbound (NAT Gateway):App servers may need to access updates or external APIs—use NAT Gateway for secure outbound connections.

Step 7: Security Best Practices

Security Groups: Only allow necessary ports (e.g., 443 for HTTPS to LB, 3306 for MySQL between app server and DB).

Network ACLs: Add another layer of subnet-level restrictions.

Encryption: Use HTTPS for all external connections, encrypt data at rest and in transit (TLS, disk encryption).

IAM Roles/Policies: Principle of least privilege for accessing resources.

Monitoring/Logging: Enable VPC flow logs, cloud service logs, and application logging.

Patch Management: Automate patching for OS and applications.

Backups: Regular, secure backups of critical data.

Step 8: Compliance Considerations

For payment applications (PCI DSS):

Isolate cardholder data environment (CDE).

Strong access controls (multi-factor authentication, role separation).

Regular vulnerability assessments and penetration testing.

Retain logs for auditing.

Step 9: Draw the Architecture (Summary)

Internet Gateway: Allows inbound/outbound internet access.

Public Subnet: WAF, Load Balancer, Autoscaling group.

Private Subnet: App servers, DB, internal LB.

NAT Gateway: Outbound access for private resources.

Security Groups/ACLs: Control all traffic flows.

Monitoring/Logging: Enabled at all levels.

Bonus: Sample Security Group Rules

Web Server (Public Subnet):

Inbound: 443 (HTTPS) from Internet

Outbound: 80/443 to App Servers

App Server (Private Subnet):

Inbound: 80/443 from Web Servers

Outbound: 3306 (MySQL) to Database

Database (Private Subnet):

Inbound: 3306 from App Servers

Outbound: None (unless replication required)

References to Security+ Domains

1.0 General Security Concepts: Principle of least privilege, defense in depth.

2.0 Threats, Vulnerabilities, Mitigations: WAF, segmentation, patching.

3.0 Security Architecture: Network segmentation, secure design.

4.0 Security Operations: Monitoring, logging, response.

5.0 Security Program Management: Compliance, policy.

When the government bans a vendor, the primary concern for the company’s general counsel is sanctions, which are legal restrictions that prohibit the purchase, use, import, or continued operation of products associated with restricted entities. Security+ SY0-701 stresses that compliance with government regulations and legal mandates is a critical oversight responsibility. Failure to comply may result in severe penalties, including fines, loss of contracting eligibility, and reputational damage.

During a hardware refresh, general counsel will ensure the organization is not violating federal trade sanctions, procurement laws, or export/import restrictions. Even if devices are already purchased, continued use may still violate the sanctions, creating legal liability.

Data sovereignty (B) relates to storage location requirements, not vendor bans. Cost of replacement (C) is an operational and financial concern, not a legal one. Loss of license (D) typically applies to software but is not the primary legal concern tied to a government-issued vendor ban.

Therefore, sanctions are the general counsel’s primary focus.

This scenario describes a partially-known environment penetration test. In CompTIA Security+ SY0-701, penetration testing approaches are commonly categorized as black box (unknown), white box (fully known), and gray box (partially known). A partially-known environment means the tester is given limited information—enough to be realistic and efficient, but not complete details about the infrastructure.

Here, the vendor is assisting an internal red team and is intentionally not provided with extensive infrastructure details, which mirrors a gray-box testing approach. This method balances realism and efficiency by simulating an attacker who has some knowledge (such as credentials, architecture diagrams, or application details) but not full access or documentation.

Passive reconnaissance (A) is an activity within testing, not a testing methodology. Integrated testing (C) refers to coordinated testing involving multiple teams (e.g., red and blue teams) with full cooperation. Defensive testing (D) focuses on validating defensive controls rather than simulating an attacker’s perspective.

Therefore, the correct answer is B: Partially-known environment.