Browse Certification Practice Tests by Exam Family

CompTIA SecurityX CAS-005: Security Engineering

Try 10 focused CompTIA SecurityX CAS-005 questions on Security Engineering, with explanations, then continue with IT Mastery.

Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.

Try CompTIA SecurityX CAS-005 on Web View full CompTIA SecurityX CAS-005 practice page

Topic snapshot

FieldDetail
Exam routeCompTIA SecurityX CAS-005
Topic areaSecurity Engineering
Blueprint weight31%
Page purposeFocused sample questions before returning to mixed practice

How to use this topic drill

Use this page to isolate Security Engineering for CompTIA SecurityX CAS-005. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.

PassWhat to doWhat to record
First attemptAnswer without checking the explanation first.The fact, rule, calculation, or judgment point that controlled your answer.
ReviewRead the explanation even when you were correct.Why the best answer is stronger than the closest distractor.
RepairRepeat only missed or uncertain items after a short break.The pattern behind misses, not the answer letter.
TransferReturn to mixed practice once the topic feels stable.Whether the same skill holds up when the topic is no longer obvious.

Blueprint context: 31% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.

Sample questions

These original IT Mastery practice questions are aligned to this topic area. Use them for self-assessment, scope review, and deciding what to drill next.

Question 1

Topic: Security Engineering

A cloud-hosted payment service cannot reach an on-premises tokenization API after a weekend security rollout. The service is in PCI scope, uses mTLS through an egress proxy, and must remain under Zero Trust segmentation. A broad bypass is not approved because the outage affects only this one service path.

Exhibit: Initial evidence

ControlObservation
DNS resolverAPI name resolves to expected private IP
FirewallAllow rule matched for cloud subnet to API port
Egress proxyTLS handshake failures after inspection enabled
IPSReset events on same flow after proxy logs

Which action is the BEST next troubleshooting step?

Options:

  • A. Roll back DNSSEC validation because name resolution is the first dependency.

  • B. Create a temporary firewall any-any rule between the cloud subnet and the API.

  • C. Disable IPS blocking for the cloud subnet until tokenization traffic succeeds.

  • D. Trace the flow in order and run scoped DNS, TCP, and TLS probes at each control boundary.

Best answer: D

Explanation: When several network controls could be involved, prioritize troubleshooting by following the actual packet and trust path rather than disabling likely controls. Here, DNS and firewall evidence suggests basic name resolution and policy matching are not the primary failure points. The proxy shows TLS failures before the IPS reset events, so the next professional step is to validate each boundary with narrow probes: DNS result, TCP connection, certificate chain/mTLS behavior through the proxy, and then IPS disposition. This approach protects PCI and Zero Trust requirements while identifying whether the proxy inspection, mTLS trust, or IPS enforcement is the true break point. The key is controlled isolation, not broad rollback.

  • IPS bypass first is tempting because resets appear in logs, but the reset may be downstream of the proxy TLS failure.
  • Any-any firewall access weakens segmentation and ignores evidence that the expected allow rule is already matching.
  • DNS rollback does not fit the observed successful resolution to the expected private IP.

Question 2

Topic: Security Engineering

A financial services company sends on-premises loan-approval records to a cloud archive and a regulator. Requirements: record contents must remain confidential and tamper-evident, the regulator must verify which officer approved each record without receiving shared secrets, and an exported analytics dataset must not contain recoverable customer PII. A proposed design uses AES-GCM plus an HMAC with a shared integration key for approvals and replaces SSNs with unsalted SHA-256 hashes. Which design change is BEST?

Options:

  • A. Encrypt each record hash with the officer’s public key and hash all PII.

  • B. Use mutual TLS, IdP login logs, and encrypted records for regulator verification.

  • C. Use AEAD, officer private-key signatures, and irreversible redaction or tokenization of PII.

  • D. Use shared-key HMACs, encrypted storage, and unsalted hashes for dataset joins.

Best answer: C

Explanation: The design is confusing several cryptographic properties. AES-GCM is an AEAD mode, so it can provide confidentiality and integrity for protected records when used correctly. A shared-key HMAC can authenticate that someone with the shared key produced a tag, but it cannot prove which officer approved the record to an external regulator because multiple systems or administrators may know the key. Officer-controlled private-key digital signatures, validated through certificates, provide stronger attribution and non-repudiation. Unsalted hashes of predictable PII such as SSNs are pseudonymization at best, not sanitization, because they are vulnerable to dictionary comparison. Sanitization requires removing the PII or transforming it so the export cannot recover or reidentify it.

  • Shared HMACs fail the non-repudiation requirement because a shared secret cannot uniquely bind approval to one officer.
  • IdP logs may support audit correlation, but they do not cryptographically bind an approval record for regulator verification.
  • Public-key encryption of hashes does not prove officer approval, and hashing PII alone does not sanitize predictable identifiers.

Question 3

Topic: Security Engineering

A security engineer is reviewing an attestation failure for a field laptop that handles regulated design files. The user reports briefly leaving the device unattended in a conference room; the laptop later booted normally but failed conditional access.

Exhibit: Hardware attestation summary

SignalFinding
Secure Boot stateEnabled
Boot sourceRemovable USB device
TPM PCR baselinePCR[0], PCR[2], PCR[4] changed
UEFI update logNo approved capsule update
OS EDR startupFirst event after boot gap
Firmware setupExternal boot allowed

Which interpretation is best supported by the exhibit?

Options:

  • A. TPM hardware replacement need

  • B. Normal Secure Boot behavior

  • C. Transient EMI measurement noise

  • D. USB boot shim or bootkit risk

Best answer: D

Explanation: Measured boot uses TPM PCR values to record early boot components, including firmware and bootloader stages. Secure Boot being enabled does not eliminate risk if removable boot is allowed and the measured boot baseline changes unexpectedly. In this exhibit, the device booted from USB, key PCRs changed, and there is no approved UEFI update to explain the change. That combination supports an evil-maid style USB boot shim or bootkit risk, requiring containment and trusted firmware/boot-chain validation before the device is trusted again. A normal OS malware finding would not fully explain the pre-OS measurement drift and boot-source evidence.

  • Secure Boot alone fails because it can still permit signed removable boot paths while attestation detects an unexpected chain.
  • TPM replacement is not supported because the TPM reported measurements; the issue is what was measured.
  • EMI noise does not plausibly explain a USB boot source, PCR drift, and an EDR startup gap together.

Question 4

Topic: Security Engineering

A pharmaceutical consortium needs to prove provenance for clinical-trial data exchanged among three companies, a cloud analytics platform, and an on-premises regulator archive. Requirements include tamper-evident history, non-repudiation by each submitting organization, deletion or anonymization of personal data after legal retention, and reasonable operational overhead. Which design is the BEST professional decision?

Options:

  • A. Use a permissioned ledger for signed hashes; keep personal data off-chain.

  • B. Publish trial-record hashes and encrypted identifiers to a public blockchain.

  • C. Use a centralized database with TLS and administrator-only audit logs.

  • D. Store encrypted patient records directly on a permissioned blockchain.

Best answer: A

Explanation: The best cryptographic design separates immutable proof from regulated personal data. A permissioned ledger can record transaction hashes, timestamps, organization signatures, and certificate references to support provenance and non-repudiation among known parties. The actual clinical records should remain off-chain in controlled repositories where retention, sanitization, anonymization, access control, and legal hold requirements can be enforced. Digital signatures bind each submission to an organization, while hashes allow later integrity verification without exposing the underlying data. Putting personal data or stable identifiers on-chain creates long-term privacy and deletion problems, even if encrypted. The key takeaway is to make the evidence immutable, not the regulated data itself.

  • On-chain records fail because encrypted personal data may still conflict with deletion, sanitization, and future confidentiality requirements.
  • Public blockchain adds unnecessary exposure and governance complexity for a known consortium and regulated clinical data.
  • Central audit logs lack independent tamper evidence and cross-organization non-repudiation for provenance disputes.

Question 5

Topic: Security Engineering

A manufacturer is deploying Linux-based edge gateways that collect safety telemetry from factory networks and publish to a cloud analytics platform. The security architecture must protect the device identity key from OS compromise, prove the gateway booted an approved firmware/kernel before cloud enrollment, and support Zero Trust access decisions without relying on a permanently connected factory network. Which design is the BEST professional decision?

Options:

  • A. Use a central cloud HSM to sign all gateway telemetry messages

  • B. Use TPM-backed measured boot, non-exportable device keys, and remote attestation

  • C. Require UEFI passwords and full-disk encryption on each gateway

  • D. Store device certificates in an encrypted filesystem unlocked during boot

Best answer: B

Explanation: A hardware root of trust should anchor both identity and integrity. A TPM can generate or protect a non-exportable private key so the operating system cannot simply copy it after compromise. Secure or measured boot records firmware, bootloader, and kernel measurements into platform configuration registers, and those measurements can be attested to a cloud verifier before issuing tokens or allowing telemetry ingestion. This supports Zero Trust because access is based on device identity plus current integrity posture, not network location. Intermittent factory connectivity is acceptable because attestation can occur when the gateway connects to the cloud control plane. Disk encryption and passwords help, but they do not prove runtime boot integrity to a relying party.

  • Encrypted filesystem only protects stored certificate files but exposes keys after unlock and does not prove boot state.
  • Cloud HSM signing protects a centralized key but does not establish each gateway’s local boot integrity or device-bound identity.
  • UEFI password and FDE reduce casual tampering and data exposure but are not sufficient for attestation-based Zero Trust decisions.

Question 6

Topic: Security Engineering

A hospital network must migrate cryptography for regulated data exchanges while preserving patient-care connectivity. Which migration path best satisfies the exhibit?

Exhibit: Migration constraints

ConstraintDetail
Data sensitivityRecords require at least 15 years of confidentiality
Regulatory expectationMaintain approved classical cryptography; document exceptions
Quantum-risk mandateReduce harvest-now-decrypt-later exposure within 12 months
Partner supportMost support TLS 1.3 ECDHE; a few legacy gateways support only RSA key exchange
Operational limitLegacy gateways cannot be replaced for 18 months

Options:

  • A. Disable encrypted transport for legacy gateways and rely on network segmentation

  • B. Deploy hybrid PQC/classical TLS where supported and time-bound legacy exceptions

  • C. Force pure PQC connections for all partners within 12 months

  • D. Keep all exchanges on current classical TLS until every gateway is replaced

Best answer: B

Explanation: The best migration path is crypto-agile and phased: use hybrid post-quantum plus approved classical key establishment where partners support it, while preserving classical compliance and reducing harvest-now-decrypt-later risk for long-lived data. The legacy RSA-only gateways create an interoperability exception, not a reason to stop the whole migration. Those connections should be isolated, monitored, formally risk-accepted, and given a sunset or replacement date aligned to the 18-month constraint. Pure PQC may fail regulatory or interoperability requirements, while waiting for all partners leaves high-value data exposed to future decryption risk.

  • Pure PQC everywhere breaks the stated legacy interoperability constraint and may not meet the approved-classical expectation.
  • Wait for replacement ignores the 12-month mandate to reduce future quantum exposure for long-lived records.
  • Segmentation only is not a substitute for encrypted transport protecting regulated data in transit.

Question 7

Topic: Security Engineering

A hybrid enterprise uses zero-trust segmentation for a payment service hosted in a cloud VPC. Policy requires all branch user traffic to reach the service only through an API gateway; direct branch-to-service connections must be blocked without disrupting production traffic. During incident triage, the SIEM shows no firewall deny events for a branch host that attempted direct TLS connections.

Exhibit: Observability summary

SourceObservation
EDR on branch hostRepeated SYNs to payment service TCP 443; no established session
SD-WAN edge flow logForwarded to segmentation firewall; return bytes = 0
Segmentation firewallDeny rule hit counter increasing; local buffer shows denies
Firewall log exportFailed after recent certificate rotation
Cloud VPC flow logsNo matching connection records

Which action is the BEST professional decision?

Options:

  • A. Create a temporary direct allow rule for troubleshooting

  • B. Add a cloud network ACL deny for the branch CIDR

  • C. Restore firewall log export and validate with a controlled test

  • D. Declare a segmentation enforcement failure and isolate the branch

Best answer: C

Explanation: This is a visibility gap, not an enforcement failure. The branch host generated SYNs, but no session was established, return bytes were zero, the cloud never saw the traffic, and the segmentation firewall’s deny counter and local buffer both show matching denies. The missing SIEM events are explained by the failed firewall log export after certificate rotation. The best response is to repair centralized logging, then run a controlled validation attempt so incident records, monitoring, and compliance evidence reflect the actual enforcement state.

Adding another deny may be useful as defense-in-depth later, but it does not fix the broken observability path. Changing access or isolating the branch would increase operational impact without evidence that the control failed.

  • Cloud ACL deny adds another control but does not address why SIEM visibility is missing.
  • Temporary allow rule weakens zero-trust enforcement and is unnecessary because local telemetry already proves the decision point.
  • Branch isolation treats the issue as containment-worthy, but the observed traffic was denied and never reached the cloud service.

Question 8

Topic: Security Engineering

A security architect is reviewing proposed cryptographic controls for a hybrid application. Which interpretation is best supported by the exhibit?

Exhibit: Crypto control mapping

Control intentProposed implementation
Slow offline guessing if the password database is stolenSalted Argon2id with approved memory and iteration settings
Prevent one custodian from reconstructing a root recovery keyShamir secret sharing with M-of-N custodians
Encrypt large object storage while limiting KMS operationsPer-object data keys wrapped by a KMS-managed key
Keep recorded TLS sessions confidential if the endpoint private key is later stolenHSM-backed RSA key exchange with TLS acceleration

Options:

  • A. The object-storage control should use direct KMS encryption only.

  • B. The TLS design confuses hardware acceleration with forward secrecy.

  • C. The password control should use key splitting instead of Argon2id.

  • D. The recovery-key control should use envelope encryption instead of sharing.

Best answer: B

Explanation: Forward secrecy protects past session confidentiality if a long-term private key is later compromised. That requires ephemeral key agreement, such as DHE/ECDHE-style session establishment, so recorded traffic cannot be decrypted from the server’s private key alone. Hardware acceleration may improve cryptographic throughput or isolate private-key use in an HSM, but it does not change a static RSA key exchange into a forward-secret design. The other mappings match their purposes: Argon2id is key stretching for password resistance, Shamir sharing is key splitting, and wrapping per-object data keys with a KMS key is envelope encryption.

  • Password substitution fails because Argon2id is appropriate key stretching; key splitting solves custodian or recovery-key control, not password guessing.
  • Direct KMS encryption fails because envelope encryption is the scalable pattern for large objects and frequent data-key use.
  • Envelope for recovery fails because splitting a recovery key across custodians addresses single-custodian reconstruction risk.

Question 9

Topic: Security Engineering

A hybrid retailer’s public API is under a sustained attack that mixes high-volume TLS connection attempts with expensive requests to /inventory/search. The API runs in cloud load-balanced containers, calls an on-premises inventory database over a private link, and must remain available for mobile customers and mTLS-authenticated partners. Security policy requires Zero Trust enforcement at the origin and a change that can be rolled back quickly. Which mitigation plan is the BEST professional decision?

Options:

  • A. Add broad subnet NACL denies for attacking geographies

  • B. Enable edge DDoS scrubbing, WAF rate limits, and origin allowlisting

  • C. Increase container and database capacity until traffic stabilizes

  • D. Bypass the WAF for mTLS partner traffic to reduce latency

Best answer: B

Explanation: The best mitigation combines upstream absorption with targeted application-layer controls and origin hardening. DDoS scrubbing and CDN/WAF controls reduce malicious traffic before it consumes cloud, private-link, or on-premises database resources. Rate limiting or request shaping on the expensive endpoint directly addresses resource exhaustion without blocking all customers. Restricting origin access to approved edge services and partner paths supports Zero Trust by preventing attackers from bypassing the protection layer. This plan is also operationally safer because edge rules and allowlists can usually be deployed and rolled back faster than major infrastructure or network redesigns. Simply scaling capacity treats the symptom and may amplify cost and database pressure.

  • Capacity-only response fails because it does not stop malicious request patterns from exhausting the private link or database.
  • Broad NACL blocking is brittle, stateless, and likely to block legitimate mobile users without addressing application-layer abuse.
  • WAF bypass weakens the enforced inspection point and creates an alternate path attackers could target or misuse.

Question 10

Topic: Security Engineering

A global manufacturer has Windows laptops, Linux build servers, and cloud-hosted workloads. Recent incidents showed that malware disabled one endpoint agent before beaconing, and network-only detections missed activity from remote users. The security architect must improve endpoint visibility and response while supporting Zero Trust segmentation and audit evidence. Which approach is the BEST professional decision?

Options:

  • A. Replace endpoint agents with perimeter IDS and full packet capture

  • B. Layer EDR with host telemetry, tamper protection, SIEM correlation, and automated containment

  • C. Standardize on disk encryption and monthly vulnerability scans

  • D. Route all remote traffic through a VPN before allowing endpoint access

Best answer: B

Explanation: The core concept is defense-in-depth for endpoint visibility and response. A mature design should combine endpoint detection and response with additional host logs, tamper resistance, centralized SIEM correlation, and controlled response automation such as isolation or credential revocation. This addresses the stated failure mode: one agent can be impaired, and network-only monitoring loses visibility when users are remote or workloads are cloud-hosted. The design also supports Zero Trust because containment can be tied to device posture and segmentation decisions, while centralized telemetry supports auditability. A single perimeter, encryption, or scanning control may be valuable, but none provides continuous multi-source endpoint visibility plus response.

  • Perimeter-only monitoring fails because remote endpoints and cloud workloads may not traverse monitored network chokepoints.
  • Encryption and scanning help protect data and reduce exposure but do not provide continuous detection or rapid containment.
  • VPN enforcement improves traffic control but still depends on one access path and does not solve compromised-host telemetry gaps.

Continue with full practice

Use the CompTIA SecurityX CAS-005 Practice Test page for the full IT Mastery practice bank, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try CompTIA SecurityX CAS-005 on Web View CompTIA SecurityX CAS-005 Practice Test

Free review resource

Read the CompTIA SecurityX CAS-005 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.

Revised on Thursday, May 28, 2026