Security+ Security Architecture: 432 practice questions

12 of the 432 Security Architecture questions in the Certsqill Security+ bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for Security+? Take the free 5-min readiness check →

1. Encrypt and classify inventory data in customer-managed: Which TWO controls directly meet that responsibility?

Select two. More than one option is correct — every correct one is ticked below.

1. Encrypt and classify inventory data in customer-managed cloud services. ✓

   The warehouse remains responsible for protecting its data through classification and appropriate encryption.
2. Apply approved security updates to the provider’s physical-host hypervisors.

   The scenario assigns physical hosts and hypervisors to the provider; guest operating-system updates would instead be a customer responsibility.
3. Review provider facility-access reports against the warehouse's physical-security policy.

   Facility security is ordinarily managed by the provider, although customers may review contractual assurance evidence.
4. Enforce role-based access and multifactor authentication for cloud administrators. ✓

   These controls protect customer-managed identities and limit administrative access to warehouse-controlled IaaS resources.
5. Configure redundancy for provider-owned power and cooling equipment.

   Power and cooling infrastructure are normally provider-managed facility responsibilities under the service agreement.

IaaS customers secure identities and data, while providers secure facilities, hardware, and hypervisors.

2. Configure role-based access with multifactor: Which control should the firm implement?

1. Deploy a customer-managed hypervisor around the SaaS application.

   SaaS customers do not normally control the provider's application hosting hypervisor or underlying virtualization layer.
2. Configure role-based access with multifactor authentication for firm users. ✓

   Customer-configured identity and authorization controls directly restrict SaaS project-file access by authorized business roles.
3. Require the provider to patch its physical database servers weekly.

   The provider owns and operates the SaaS infrastructure, including server patching and maintenance activities.
4. Build a separate network perimeter around the provider's application.

   A customer cannot usually place a traditional network perimeter around a provider-operated SaaS application.

In SaaS, the customer still manages user identities and data access, even though the provider manages the application platform.

3. Federate cloud authentication through the nonprofit’s: Which control should be implemented next?

1. Federate cloud authentication through the nonprofit’s identity provider. ✓

   Federation lets cloud services rely on the nonprofit’s managed identity boundary and its established authentication policy.
2. Place the cloud applications behind an internal network firewall.

   A firewall can restrict traffic but cannot unify authentication policies or prevent unmanaged cloud accounts.
3. Replicate each local password into every cloud application database.

   Password replication increases exposure and still lacks centralized policy enforcement and modern federation benefits.
4. Use a separate cloud password vault.

   A vault may protect stored secrets but does not connect cloud authentication to the approved identity policy.

Federation connects cloud authentication to the existing identity provider and reduces unmanaged parallel credentials.

4. Complete a supplier assessment and put security duties: Which control should occur before integration?

1. Complete a supplier assessment and put security duties in the contract. ✓

   Due diligence and contractual requirements establish expectations for data handling, availability, incident reporting, and other supplier responsibilities before integration.
2. Migrate the scheduling application to larger infrastructure before connection.

   Additional capacity does not evaluate supplier trust, data handling, contractual duties, or dependency risk.
3. Require provider endpoint protection and quarterly evidence before connection.

   Endpoint protection may be relevant, but this narrow measure does not replace a broader supplier assessment and contractual requirements.
4. Defer the connection until business approval is renewed.

   The business need is already approved; delaying it without assessing the supplier does not address the missing security governance.

Assess the supplier and establish contractual security requirements before creating the dependency.

5. Require peer review and automated policy checks before IaC: Which control best prevents the same mistake from

1. Disable infrastructure as code and build every server manually.

   Manual construction removes repeatability and increases configuration drift without addressing the underlying review weakness.
2. Allow administrators to edit each environment independently after deployment.

   Manual divergence reduces consistency and makes repeated configuration errors harder to detect and control.
3. Increase production server memory before the next deployment.

   Additional memory affects capacity and does not identify or prevent repeated insecure infrastructure settings.
4. Require peer review and automated policy checks before IaC deployment. ✓

   Review and automated validation detect insecure configurations before approved code is applied broadly.

Predeployment review and policy validation stop a flawed template from propagating across many environments.

6. Run the untrusted workload in a separate virtual machine: Which design is most appropriate?

1. Increase the container registry retention period.

   Image retention supports recovery or version management but does not isolate running workloads from each other.
2. Run the untrusted workload in a separate virtual machine. ✓

   A VM normally provides a stronger isolation boundary because workloads do not directly share the host kernel.
3. Place both workloads in the same container image.

   Combining workloads increases coupling and does not strengthen isolation between untrusted and claims-processing functions.
4. Add more containers to the existing host without changing placement.

   Additional containers still share the same host kernel and do not address the requested stronger boundary.

Containers share a host kernel; placing the higher-risk workload in a separate VM creates a stronger isolation boundary.

7. Place each service in a separate virtual machine: Which architectural change most directly strengthens their s

1. Store the workloads on separate virtual disks and restrict access.

   Separate virtual disks can protect storage access, but they do not provide independent execution boundaries equivalent to separate VMs.
2. Place each service in a separate virtual machine. ✓

   Separate virtual machines provide distinct guest execution boundaries between the public and internal workloads.
3. Place both services behind separate application roles.

   Application roles improve authorization but do not create a stronger workload or operating-system boundary.
4. Assign additional CPU capacity to the enrollment service.

   Resource allocation can improve performance but does not establish a security boundary between the services.

Separate virtual machines create a stronger execution boundary between the public and internal services.

8. Validate and authorize inputs at the function interface: Which TWO controls directly address those customer du

Select two. More than one option is correct — every correct one is ticked below.

1. Install a customer-managed hypervisor beneath each function.

   Serverless customers generally do not control or install hypervisors beneath provider-managed execution environments.
2. Validate and authorize inputs at the function interface. ✓

   Application-level validation and authorization remain customer responsibilities despite the provider managing server infrastructure.
3. Replace the provider's runtime patching team with warehouse administrators.

   The provider manages the serverless runtime and underlying patching, not the warehouse customer.
4. Assign each function a least-privilege execution role. ✓

   Narrow execution permissions limit what a function can access if its code or invocation is abused.
5. Purchase additional physical racks for the provider's data center.

   Data-center capacity and physical facilities are provider-managed responsibilities in a serverless service.

Serverless removes server administration, not responsibility for function permissions, input handling, and application behavior.

9. Validate API requests and enforce rate limits: Which TWO controls most directly reduce the resulting interface

Select two. More than one option is correct — every correct one is ticked below.

1. Increase storage capacity for the billing database.

   More storage addresses capacity but does not establish service identity or protect exposed interfaces.
2. Validate API requests and enforce rate limits at the service boundary. ✓

   Validation limits malformed or unauthorized requests, while rate limiting reduces abuse of exposed interfaces.
3. Allow each service team to define unrelated authentication formats.

   Uncoordinated formats increase inconsistency and make centralized verification and monitoring more difficult.
4. Authenticate service-to-service calls using workload identities. ✓

   Workload authentication establishes which service is calling instead of trusting network location alone.
5. Place every service on one shared host network without restrictions.

   A shared unrestricted network preserves implicit trust and increases lateral movement opportunities between services.

Microservices need explicit workload identity and protected interfaces because network location alone should not establish trust.

10. Scan and approve removable media before entry into: Which TWO controls best preserve the air gap and address t

Select two. More than one option is correct — every correct one is ticked below.

1. Document the air gap and review its physical boundaries periodically.

   Periodic review helps verify the architecture but does not directly inspect or control malware carried on maintenance media.
2. Scan and approve removable media before entry into the control environment. ✓

   Pre-entry inspection reduces the chance that maintenance media introduces malicious or unauthorized content.
3. Use a controlled media-transfer process with approved custodians. ✓

   Custody procedures restrict how removable media crosses the physical boundary and provide accountability for transfers.
4. Replicate selected control data to business servers through an approved transfer process.

   Data replication creates a communication path and changes the approved air-gap design, even when the transfer is controlled.
5. Use a dedicated VLAN for maintenance devices inside the control environment.

   A VLAN is logical segmentation within a network and does not itself control malware introduced through removable media.

Controlled custody and pre-entry scanning address the manual media path without replacing the approved air gap.

11. Enforce firewall policy between network segments: Which control directly meets the objective?

1. Enforce firewall policy between network segments. ✓

   Inter-segment firewall rules restrict permitted paths and directly limit unauthorized movement toward payment systems.
2. Place all systems on a single VLAN.

   A shared VLAN reduces administrative complexity but does not create meaningful separation between application tiers.
3. Create a physically separate payment network.

   Physical separation can isolate systems, but it may unnecessarily prevent approved application communication and increase operational complexity.
4. Encrypt traffic between every application component.

   Encryption protects data in transit but does not prevent an authorized or compromised host from reaching payment services.

Firewall-enforced segmentation directly restricts traffic between tiers while allowing specifically approved application flows.

12. Cache approved policies for local enforcement: Select TWO controls that best meet both needs.

Select two. More than one option is correct — every correct one is ticked below.

1. Let each branch create independent security rules.

   Independent rules preserve local autonomy but increase inconsistency, duplication, and the likelihood of divergent access decisions.
2. Replace branch controls with a single perimeter firewall.

   A perimeter firewall cannot enforce local resource policies for users and systems distributed across separate branches.
3. Cache approved policies for local enforcement. ✓

   Local policy caches preserve branch operation during connectivity loss while retaining centrally approved policy content.
4. Route all branch authorization decisions through headquarters.

   Central authorization can improve consistency but makes branch access dependent on WAN availability and headquarters responsiveness.
5. Centralize policy definition and approval. ✓

   Central administration improves consistency by allowing headquarters to define, review, and update common access requirements.

Central governance supplies consistency, while cached local enforcement preserves operations during temporary connectivity loss.

Other Security+ domains

• Security Operations — 672 questions →
• Threats, Vulnerabilities, and Mitigations — 527 questions →
• Security Program Management and Oversight — 480 questions →
• General Security Concepts — 287 questions →
• All 2398 Security+ questions →
• Security+ certification: requirements, cost and exam format →