CAS-005 — CompTIA SecurityX (CAS-005) Exam Quick Reference

Compact CAS-005 Quick Reference for CompTIA SecurityX exam candidates: architecture, engineering, operations, GRC, IAM, cloud, crypto, and incident response decision points.

Quick Reference focus

This independent Quick Reference is for candidates preparing for CompTIA SecurityX (CAS-005). Use it to review advanced security architecture, engineering, operations, and governance decision points before doing original practice questions and performance-based tasks.

SecurityX questions often ask for the best control in context, not just a definition. Anchor each answer on:

Exam cueAsk yourselfStrong answer pattern
Enterprise architectureWhat reduces risk at scale without breaking operations?Layered controls, segmentation, identity-first access, automation, measurable governance
“Most secure”What blocks the threat while preserving business requirements?Least privilege, deny by default, strong crypto, managed keys, centralized logging
“Best next step”What phase is the team in?Identify before contain; contain before eradicate; validate before closeout
“Cost-effective”Can an existing control or managed service solve it?Prioritize risk reduction, automation, and operational simplicity
“Compliance”What provides evidence and repeatability?Policies, standards, control mapping, audit trails, exception process
“Zero trust”Is access continuously evaluated?Identity, device posture, context, segmentation, least privilege, telemetry
“High availability”What fails over without data loss beyond tolerance?RTO/RPO-driven design, redundancy, tested recovery
“Cloud security”Who owns the control in the shared model?IAM, data protection, configuration, monitoring, and workload security

Architecture decision matrix

RequirementPreferWhyWatch for
Replace broad network VPN accessZTNAApp-level access, identity/context checks, reduced lateral movementZTNA is not “install MFA and keep flat network”
Limit east-west movementMicrosegmentationControls workload-to-workload communicationNeeds asset inventory and policy lifecycle
Secure remote branch/cloud accessSASE/SSE patternCombines secure web gateway, CASB, ZTNA, DLP, policy enforcementAvoid assuming all SASE products provide identical controls
Protect web apps from common attacksWAF + secure code fixesWAF reduces exposure; code fixes remove root causeWAF is compensating, not a substitute for remediation
Protect APIsAPI gateway + authz + schema validation + rate limitsHandles authentication, authorization, throttling, loggingOAuth scopes are not enough without object-level authorization
Isolate privileged administrationPAM + jump host/bastion + session recordingControls, monitors, and limits admin pathsShared admin accounts break attribution
Reduce credential theft impactPhishing-resistant MFA + conditional access + PAMStronger auth and just-in-time privilegeSMS/OTP MFA is weaker than FIDO2/WebAuthn
Meet strict key custody needsHSM or cloud KMS with appropriate key ownership modelProtects key material and centralizes lifecycleBYOK/HYOK improves control but adds operational burden
Detect unknown endpoint behaviorEDR/XDRBehavioral telemetry, response actions, investigationEDR does not replace hardening and patching
Detect network lateral movementNDREast-west traffic analytics and anomaly detectionEncrypted traffic may need metadata or endpoint correlation
Centralize event correlationSIEMLog aggregation, rules, correlation, investigationSIEM detects; it does not automatically remediate
Automate repetitive responseSOARPlaybooks, enrichment, ticketing, containmentBad playbooks can amplify false positives
Protect SaaS usage and dataCASBVisibility, DLP, access controls, shadow IT discoveryNeeds integration with IdP and SaaS platforms
Reduce cloud misconfigurationCSPM + policy as codeContinuous posture checks and guardrailsFindings still require ownership and remediation workflow
Protect cloud workloadsCWPPRuntime, host, container, and workload protectionDifferent from CSPM, which focuses on posture
Unified cloud security programCNAPPCombines posture, workload, identity, IaC, and runtime viewsDo not assume one tool removes need for architecture decisions

Zero trust reference

Zero trust is an architecture approach, not a single product.

PrinciplePractical implementationEvidence to look for
Verify explicitlyStrong identity, device posture, location, risk score, app sensitivityConditional access policies, IdP logs, device compliance
Least privilegeRBAC/ABAC, JIT/JEA admin, scoped tokens, short-lived credentialsAccess reviews, privilege reports, PAM logs
Assume breachSegmentation, continuous monitoring, deception, rapid containmentEDR/NDR telemetry, segmentation policy, tested IR playbooks
Continuous evaluationReassess sessions based on risk changesToken revocation, re-auth triggers, adaptive policies
Protect dataClassification, encryption, DLP, tokenization, retention controlsData inventory, DLP incidents, key management logs

Zero trust traps

TrapCorrect interpretation
“We use MFA, so we have zero trust.”MFA is one control. Zero trust also needs least privilege, context, segmentation, telemetry, and continuous enforcement.
“Zero trust means no network controls.”Network segmentation still matters; zero trust reduces implicit trust.
“ZTNA is always better than VPN.”ZTNA is preferred for app-specific access; VPN may still exist for legacy or administrative use with compensating controls.
“Device trust is permanent.”Device posture should be continuously checked and can change during a session.

IAM and access control

Protocols and identity components

ComponentUse whenKey detailsCommon trap
SAML 2.0Enterprise browser-based SSOXML assertions between IdP and service providerGood for federation, not modern API authorization
OAuth 2.0Delegated authorizationAccess tokens grant scoped access to resourcesOAuth is not an authentication protocol by itself
OpenID ConnectAuthentication on top of OAuth 2.0Adds ID token and user identity claimsDo not use ID token as API authorization token
KerberosInternal enterprise authenticationKDC, tickets, mutual auth, time sensitivityClock skew and SPN issues cause failures
LDAP/LDAPSDirectory queries and identity store accessLDAPS protects directory trafficLDAP is not the same as SSO
RADIUSNetwork access authenticationCommon for VPN, Wi-Fi, NACLimited command authorization
TACACS+Network device administrationSeparates authn, authz, and accountingPreferred for granular admin command control
SCIMIdentity provisioningAutomates user/group lifecycle into SaaS appsFederation without provisioning leaves orphaned accounts
FIDO2/WebAuthnPhishing-resistant MFAPublic key authentication, origin bindingStronger than SMS or push-only MFA

Access models

ModelBest fitStrengthWeakness
RBACJob roles are stableSimple to audit and administerRole explosion in complex environments
ABACDynamic context mattersUses attributes: user, device, data, location, riskRequires strong attribute governance
DACOwner-controlled accessFlexible for collaborationLess centralized control
MACHighly classified or rigid environmentsStrong central policy enforcementOperationally inflexible
ReBACRelationship-based accessUseful for social/collaboration graphsComplex policy reasoning
PBAC/XACML-styleCentralized policy decisionsDecouples policy from applicationsNeeds mature policy design

Privileged access controls

ControlPurposeExam decision point
PAM vaultStores and rotates privileged secretsUse for administrator, service, and break-glass accounts
JIT accessGrants privilege only when neededReduces standing privilege
JEAGrants only required admin capabilityStronger than broad temporary admin
Session recordingAccountability and forensicsUseful for sensitive admin access and third-party support
Break-glass accountEmergency accessMust be protected, monitored, tested, and tightly controlled
Service account governancePrevents unmanaged machine privilegesUse rotation, scoped permissions, ownership, and noninteractive controls

Cryptography and PKI

Crypto selection table

NeedPreferNotes
Fast bulk data encryptionSymmetric encryption, such as AES-GCMGCM provides authenticated encryption when used correctly
Secure key exchange over untrusted networkECDHE/DHEEnables perfect forward secrecy when ephemeral keys are used
Digital signatureRSA/ECDSA/EdDSA-style signature schemesProvides integrity, authenticity, and nonrepudiation support
Password storageSalted adaptive hash/KDFUse bcrypt, scrypt, Argon2, or PBKDF2-style approach; never plain hash alone
Message integrity with shared secretHMACStronger than plain hash for authenticity
File integrity check onlyCryptographic hashDetects change, does not provide secrecy
Key protectionHSM/KMS/TPMReduces key exposure and centralizes lifecycle
Transport securityTLS with modern cipher suitesValidate certificates and avoid weak protocols/ciphers
Mutual service identitymTLSBoth client and server present certificates
Data field substitutionTokenizationReduces exposure of sensitive values in applications
Format-preserving protectionFormat-preserving encryption or tokenizationUseful where legacy field format must remain

PKI terms that matter

TermPractical meaning
Root CATrust anchor; compromise affects all subordinate trust
Intermediate CAIssues certificates while protecting root CA offline
Certificate chainPath from leaf certificate to trusted root
CSRCertificate signing request containing public key and identity information
CRLPublished list of revoked certificates
OCSPOnline certificate status check
OCSP staplingServer provides status proof to reduce client lookup overhead
Certificate pinningApp trusts specific cert/key; improves control but complicates rotation
SANSubject Alternative Name; modern identity field for DNS names
mTLSMutual certificate authentication for client and server
Key escrowThird party stores recoverable key material; useful but increases risk
Key rotationPeriodic or event-driven key replacement
Key destructionRemoves ability to decrypt; must align with retention/legal hold needs

Crypto traps

StatementCorrection
“Hashing encrypts data.”Hashing is one-way integrity verification, not encryption.
“Encoding protects secrets.”Encoding such as Base64 is reversible representation, not security.
“TLS solves all API security.”TLS protects transport; API authorization, validation, and rate limiting are still required.
“Use the same key everywhere for simplicity.”Use separation of duties, key hierarchy, and scoped keys.
“Hard-coded secrets are acceptable if the repo is private.”Use a secrets manager and rotate exposed secrets.
“Old clients require weak ciphers, so keep them enabled globally.”Isolate legacy support and document risk exceptions.

Data protection and privacy engineering

ControlBest useDistinction
Data classificationDrives handling requirementsMust be tied to labels, storage, access, retention, and DLP
Encryption at restProtects stored data from unauthorized access to media/storageDoes not stop authorized misuse
Encryption in transitProtects data crossing networksRequires proper certificate validation
TokenizationReplaces sensitive value with tokenOften reduces sensitive data exposure in apps
MaskingHides part of data in display or test setsStatic masking changes copy; dynamic masking changes view
AnonymizationIrreversibly removes identity linkHard to guarantee with rich datasets
PseudonymizationReplaces identifiers but can be re-linked with extra dataStill sensitive if reidentification is possible
DLPDetects or blocks sensitive data movementNeeds classification, tuning, and workflow
DRM/IRMControls document usage after distributionUseful for sensitive documents, not all data flows
DAMMonitors database access and activityUseful for high-value structured data
Data minimizationCollect less dataReduces breach impact and compliance scope
Retention policyKeeps data only as long as requiredMust align with business, legal hold, and disposal needs
Secure disposalPrevents recovery after useUse media-appropriate sanitization and verification

Cloud and hybrid security

Shared responsibility cues

ModelProvider typically handles more ofCustomer still owns
IaaSPhysical facilities, hardware, core virtualizationOS, applications, data, IAM, network configuration, logging choices
PaaSManaged runtime/platform componentsApp code, data, identity, secrets, platform configuration
SaaSApplication hosting and maintenanceUser access, data governance, configuration, integrations, monitoring exports
On-premisesCustomer owns nearly everythingFull stack security, physical to application

Cloud control selection

ProblemChooseWhy
Public storage exposureCSPM finding + preventive policy + remediationDetects and prevents misconfiguration
Excessive cloud permissionsCIEM + least privilege reviewFinds unused, risky, and overbroad entitlements
Runtime container compromiseCWPP/EDR for containersObserves workload behavior and can respond
Insecure IaC templateIaC scanning + policy as codeStops misconfigurations before deployment
Secrets in repositorySecrets scanning + secrets manager + rotationRemoves static secrets from code
Multi-account governanceLanding zone/organization guardrailsStandardizes logging, identity, network, and policy boundaries
SaaS data leakageCASB + DLP + IdP integrationControls access and data movement
Cloud key controlKMS/HSM with rotation and access policyCentralized key lifecycle and audit
Workload identityFederated workload identityAvoids long-lived static cloud keys
Cloud incident investigationCentralized logs + immutable storage + snapshotsPreserves evidence and enables timeline reconstruction

Container and Kubernetes security

LayerControls
ImageMinimal base image, signed images, vulnerability scan, SBOM, no secrets
RegistryAccess control, image signing verification, retention, scanning
PodNon-root user, read-only filesystem where possible, resource limits
SecretsExternal secrets manager or encrypted secret storage; no secrets in images
NetworkDefault deny, namespace segmentation, service-level allow rules
AdmissionPolicy enforcement for allowed registries, privileged containers, capabilities
RuntimeBehavior monitoring, syscall restrictions, container-aware EDR/CWPP
ClusterRBAC least privilege, audit logs, secure API server, patching

Example concept: default deny plus explicit allow.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-then-allow-api
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 8443

Key interpretation: only selected web pods can reach selected api pods on TCP 8443; other ingress to those API pods is denied if policy is enforced by the CNI.

Network and infrastructure security

TechnologyBest useKey distinction
Stateless ACLSimple packet filteringDoes not track sessions
Stateful firewallNetwork/session controlAllows return traffic based on state
NGFWApp/user-aware filteringAdds application identity, threat features
IDSDetects suspicious trafficOut-of-band; usually does not block
IPSBlocks suspicious trafficInline; tuning matters to avoid disruption
WAFHTTP/S application protectionLayer 7 web traffic, not all protocols
API gatewayAPI routing, auth, throttling, observabilityComplements, not replaces, app authorization
NAC/802.1XControls network admissionUses identity/device posture
NDRNetwork behavior analyticsUseful for lateral movement and unmanaged devices
DNS filteringBlocks malicious domainsGood early control; can be bypassed if unmanaged DNS allowed
DNSSECAuthenticates DNS data origin/integrityDoes not encrypt DNS queries
DoH/DoTEncrypts DNS transportCan reduce enterprise DNS visibility if unmanaged
VPNEncrypted network tunnelOften broad network access unless tightly segmented
ZTNAApp-specific remote accessBetter least privilege for private apps
DDoS protectionAbsorbs/filters volumetric and app-layer attacksNeeds upstream/provider support and runbooks
Network segmentationLimits blast radiusEnforce with firewalls, VLANs, SDN, microsegmentation
Honeypot/deceptionDetects attacker interactionMust be isolated and monitored

OT/ICS security cues

OT constraintSecurity response
Safety and availability dominateAvoid disruptive scanning; use passive monitoring where possible
Legacy systems cannot patch quicklySegment, monitor, restrict access, use compensating controls
Vendor remote access is requiredUse PAM, MFA, jump hosts, session logging, time-bound access
Flat plant networkCreate zones/conduits and restrict IT/OT paths
Protocols lack auth/encryptionIsolate, monitor command patterns, wrap access through secure gateways
Change windows are rareTest changes, document rollback, coordinate with operations

Secure engineering and DevSecOps

Security testing tools

Tool/typeFindsBest stageLimitations
SASTSource/code-level flawsEarly developmentFalse positives; may miss runtime issues
DASTRuntime web/app flawsTest/stagingNeeds running app; may miss code paths
IASTRuntime issues with instrumentationTestRequires agent/instrumentation
SCAVulnerable dependencies/licensesBuild and CIMust manage transitive dependencies
Container scanOS/package/image flawsBuild/registryImage clean at build can become stale
IaC scanMisconfigured infrastructure templatesBefore deployNeeds policy alignment
Secrets scanExposed keys/passwords/tokensCommit/CI/repositoryDetection must trigger rotation
FuzzingCrash/input handling flawsTestRequires harness and triage
RASPRuntime app self-protectionProductionNot a replacement for secure code
Pen testExploitable pathsPre-release or periodicPoint-in-time assessment
Red teamDetection and response validationMature programsGoal is objective-based, not full coverage

Secure SDLC gates

PhaseSecurity activities
RequirementsData classification, abuse cases, compliance/control needs
DesignThreat modeling, architecture review, trust boundaries
DevelopmentSecure coding, peer review, secrets handling
BuildSAST, SCA, IaC scan, container scan, signing
TestDAST, IAST, fuzzing, security regression tests
ReleaseChange approval, artifact integrity, deployment guardrails
OperateLogging, monitoring, vulnerability management, incident playbooks
ImproveLessons learned, metrics, backlog remediation

Threat modeling quick map

Method/conceptUse
STRIDESpoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege
Attack treesDecompose attacker goals into paths
PASTA-style approachRisk-centric threat modeling tied to business impact
MITRE ATT&CKMap adversary tactics, techniques, and detection coverage
Kill chainUnderstand attack progression and control placement
Abuse casesDefine how features can be misused
Trust boundaryWhere data/control crosses privilege, network, or ownership boundary

API and application security cues

IssueBest control
SQL/LDAP/command injectionParameterized queries, safe APIs, input validation, least privilege
XSSOutput encoding, CSP, input validation, secure frameworks
CSRFAnti-CSRF tokens, SameSite cookies, re-auth for sensitive actions
SSRFEgress filtering, metadata service protection, allowlists, URL validation
Broken object-level authorizationServer-side authorization checks per object
Excessive data exposureResponse filtering, schema control, least data return
Weak JWT handlingValidate signature, issuer, audience, expiry; avoid accepting none algorithm
Token leakageSecure storage, short lifetimes, refresh token rotation
Insecure deserializationAvoid unsafe deserialization, sign/validate serialized data
File upload riskType validation, malware scan, storage isolation, no direct execution
Rate abuseRate limiting, quotas, bot controls, anomaly detection
Insecure CORSRestrict origins, methods, credentials; avoid wildcard with credentials

Supply chain security

RiskControls
Malicious dependencySCA, dependency pinning, trusted registries, package integrity checks
Compromised build pipelineLeast privilege CI/CD, isolated runners, signed builds, secrets manager
Tampered artifactCode signing, artifact signing, provenance verification
Unknown componentsSBOM generation and inventory
Developer account takeoverPhishing-resistant MFA, conditional access, branch protection
Secret exposurePre-commit/CI secrets scanning and immediate rotation
Unreviewed codePull request reviews, CODEOWNERS-style approvals, protected branches
Third-party service riskDue diligence, contract controls, monitoring, exit plan

Security operations

Tool selection by operational need

NeedPrimary tool/controlWhy
Correlate logs across enterpriseSIEMCentral search, correlation, alerting
Automate enrichment and containmentSOARPlaybooks and integrations
Endpoint detection and responseEDRProcess, file, registry, memory, and response actions
Extended correlation across domainsXDREndpoint, identity, email, cloud, and network correlation
User/entity anomaly detectionUEBABaselines behavior and flags anomalies
Network behavior visibilityNDRDetects lateral movement and unusual traffic
Threat intel managementTIPNormalizes and distributes indicators/intel
Vulnerability trackingVM platformAsset risk, scan findings, remediation workflow
Attack surface visibilityASM/EASMExternal exposure discovery
Configuration complianceCSPM/SCAP/policy toolsDetects drift from baselines

Incident response workflow

    flowchart TD
	    A[Alert or report] --> B{Validate?}
	    B -- False positive --> C[Document and tune]
	    B -- True incident --> D[Classify severity and scope]
	    D --> E[Preserve evidence]
	    E --> F{Active threat?}
	    F -- Yes --> G[Contain: isolate, block, disable, revoke]
	    F -- No --> H[Investigate root cause]
	    G --> H
	    H --> I[Eradicate: remove malware, patch, rotate secrets]
	    I --> J[Recover and monitor]
	    J --> K[Lessons learned and control improvements]

Incident phase decision table

PhaseGoalTypical actions
PreparationBe ready before incidentsPlaybooks, contacts, tools, logging, tabletop exercises
IdentificationConfirm and scopeTriage alerts, correlate logs, determine affected assets
ContainmentStop spread/damageIsolate host, block IOC, disable account, revoke token
EradicationRemove causeRemove malware, close persistence, patch, rotate credentials
RecoveryRestore safelyRebuild, restore backups, monitor for reinfection
Lessons learnedImprove controlsRoot cause, metrics, detection tuning, policy updates

Containment choices

SituationPreferAvoid
Malware actively spreadingNetwork isolate host or segmentPowering off before volatile evidence if forensics required
Stolen credentialsDisable account, revoke sessions/tokens, reset credentialsOnly changing password while sessions remain valid
Leaked API keyRevoke/rotate key, search usage, update secret storeLeaving old key active “temporarily”
Ransomware on one hostIsolate, preserve evidence, check lateral movementImmediately restoring without understanding entry point
DDoSActivate provider mitigation, rate limits, traffic filteringLocal-only response if upstream saturated
Compromised cloud roleDisable/limit role, review activity logs, rotate credentialsDeleting evidence before timeline is built

Forensics quick reference

ConceptPractical meaning
Order of volatilityCollect most volatile evidence first when feasible: memory, network state, running processes, disk, backups
Chain of custodyDocument who collected, handled, transferred, and stored evidence
Hashing evidenceProves integrity of acquired images/files
Write blockerPrevents modification of source media during acquisition
Timeline analysisReconstructs sequence of attacker and system events
Memory captureUseful for malware, keys, processes, network connections
Disk imagePreserves filesystem and deleted artifacts
Log preservationCentralized, time-synchronized, immutable logs improve investigation
Legal holdSuspends normal deletion where required by counsel/process

Logs and detection patterns

Common log interpretation cues

EvidencePossible meaningNext check
Many failed logins then successBrute force or password sprayingSource IPs, target accounts, MFA status, impossible travel
New admin accountPrivilege escalation or legitimate changeChange ticket, creator account, directory audit logs
PowerShell encoded commandPossible obfuscationParent process, command line, script block logs
Rare outbound domainCommand and control or new SaaSDNS logs, proxy logs, reputation, host process
Large outbound transferExfiltration or backupDestination, data type, user, timing
Login from new geographyAccount compromise or travelConditional access, MFA, device posture
Repeated 401/403Credential attack or broken integrationUser agent, source, endpoint, account lockouts
Repeated 500 errorsApp issue or exploit attemptWeb logs, WAF events, payloads
New scheduled task/servicePersistenceCreator, binary path, hash, endpoint telemetry
Disabled security toolDefense evasionAdmin action logs, EDR health, process history

Generic Sigma-style detection example

title: Suspicious Encoded PowerShell
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - '-enc'
      - '-encodedcommand'
  condition: selection
fields:
  - Image
  - ParentImage
  - CommandLine
  - User
  - Hostname
level: high

Exam interpretation: encoded PowerShell is suspicious, but triage should confirm parent process, user context, script content, endpoint history, and business justification.

Vulnerability management and testing

ActivityPurposeOutput
Asset discoveryKnow what existsAsset inventory and ownership
Vulnerability scanIdentify known weaknessesFindings, severity, affected systems
Configuration scanDetect baseline driftMisconfiguration reports
Risk-based prioritizationFix what matters mostRemediation order based on exploitability, exposure, asset value
Patch managementApply vendor fixesChange records and validation
Exception processAccept temporary residual riskOwner, justification, compensating controls, expiration
Penetration testValidate exploitabilityFindings with proof and remediation guidance
Red team exerciseTest detection/response against objectivesGaps in controls, process, and monitoring
Purple teamImprove detections collaborativelyTuned detections and response playbooks
Bug bountyContinuous external researcher testingValidated reports and coordinated disclosure

Prioritization factors

Do not prioritize by scanner score alone. Consider:

  • Internet exposure
  • Known exploitation
  • Asset criticality
  • Data sensitivity
  • Compensating controls
  • Ease and reliability of exploit
  • Business impact of patching
  • Availability of mitigation
  • Regulatory or contractual commitments
  • Whether the weakness enables privilege escalation or lateral movement

Governance, risk, and compliance

Risk calculations

Use these formulas when a scenario gives enough values.

\[ \text{SLE} = \text{Asset Value} \times \text{Exposure Factor} \]\[ \text{ALE} = \text{SLE} \times \text{ARO} \]\[ \text{Risk} = \text{Likelihood} \times \text{Impact} \]
TermMeaning
Asset valueBusiness value of the asset
Exposure factorPercentage of asset value lost in one event
SLESingle loss expectancy
AROAnnualized rate of occurrence
ALEAnnualized loss expectancy
Inherent riskRisk before controls
Residual riskRisk remaining after controls
Risk appetiteAmount of risk organization is willing to accept
Risk toleranceAcceptable variation around appetite
Control effectivenessHow much a control reduces likelihood or impact

Risk treatment

TreatmentUse whenExample
MitigateReduce likelihood or impactAdd MFA, segmentation, patching
TransferShift financial/operational impactCyber insurance, contractual transfer
AvoidStop risky activityDecommission vulnerable public service
AcceptResidual risk is within appetiteDocumented exception with owner and review date

Control types

ClassificationExamples
AdministrativePolicies, standards, training, risk assessments
TechnicalMFA, encryption, firewalls, EDR, DLP
PhysicalLocks, cameras, guards, secure disposal bins
PreventiveAccess control, hardening, secure coding
DetectiveSIEM alerts, IDS, audits
CorrectiveRestore from backup, patch, reimage
DeterrentWarning banners, visible cameras
CompensatingAlternative control when primary control is not feasible
DirectivePolicies, procedures, required standards
RecoveryBackups, DR site, failover

Governance artifacts

ArtifactPurpose
PolicyHigh-level management intent and mandatory rules
StandardSpecific mandatory requirements
ProcedureStep-by-step instructions
GuidelineRecommended practice
BaselineMinimum secure configuration
Control frameworkOrganized catalog of controls
Risk registerTracks risks, owners, ratings, treatment plans
Exception registerTracks approved deviations and expiration
BIAIdentifies critical processes and outage impact
SLA/OLADefines service expectations internally/externally
MOU/MOADefines shared responsibilities between organizations
NDAProtects confidential information
DPA/data processing termsDefines data handling responsibilities

Business continuity and disaster recovery

Metric/designMeaningDecision point
BIADetermines criticality and impact over timeDrives recovery priorities
MTD/MAOMaximum tolerable downtime/outageRTO must fit inside this tolerance
RTOTarget time to restore serviceShorter RTO usually costs more
RPOAcceptable data loss windowDrives backup/replication frequency
Hot siteReady-to-run alternate siteFast recovery, higher cost
Warm sitePartially preparedBalance of cost and speed
Cold siteSpace/infrastructure onlySlower recovery, lower cost
Active-activeMultiple active locationsHigh availability and load sharing
Active-passiveStandby environmentSimpler, may have failover delay
BackupCopy of dataNot sufficient unless restore is tested
Immutable backupResistant to modification/deletionImportant for ransomware resilience
Tabletop exerciseDiscussion-based validationGood for roles and decisions
Failover testTechnical validationConfirms recovery design works

Third-party and vendor risk

AreaWhat to verify
Due diligenceSecurity posture, financial/operational stability, references
Data accessWhat data, where stored, who can access it
Contract termsSecurity obligations, audit rights, breach notification expectations
SubcontractorsUse of subprocessors and flow-down obligations
Identity integrationSSO, MFA, provisioning/deprovisioning
LoggingAvailability of audit logs and export/API access
EncryptionAt rest, in transit, key ownership options
ResilienceBackup, DR, availability commitments
Exit strategyData return/deletion, portability, transition support
Continuous monitoringSecurity reports, attestations, issue tracking

Privacy and data governance cues

PrinciplePractical security action
Purpose limitationCollect/use data only for defined purposes
Data minimizationReduce fields collected and retained
Consent/notice managementAlign user expectations with processing
Retention limitationDelete or anonymize when no longer needed
Access rights supportMaintain searchable inventories and workflows
Privacy by designInclude privacy in requirements and architecture
Data localizationUnderstand where data is stored and processed
Cross-border transfer reviewVerify contractual and organizational controls
DeidentificationUse anonymization/pseudonymization where appropriate
Breach readinessKnow data owners, notification workflow, and evidence sources

Common CAS-005 decision traps

Trap answerBetter exam reasoning
“Encrypt it” for every data problemEncryption protects confidentiality but does not solve authorization, retention, misuse, or integrity by itself.
“Block everything immediately” during incident responsePreserve evidence and choose containment proportional to business impact and active threat.
“Patch the highest CVSS first”Prioritize using exploitability, exposure, asset criticality, and business context.
“Move to cloud for better security”Cloud changes control ownership; misconfiguration and IAM risk remain.
“Use SIEM to prevent attacks”SIEM detects and correlates; prevention requires controls and response actions.
“Use blockchain for integrity”Most integrity requirements are better met with hashes, signatures, logs, and access controls.
“Use AI/ML for any anomaly”ML needs quality data, tuning, explainability, and operations workflow.
“IDS blocks the attack”IDS detects; IPS blocks inline.
“Tokenization and encryption are the same”Tokenization substitutes values; encryption transforms data with keys.
“Backups equal resilience”Backups must be isolated, restorable, tested, and aligned to RTO/RPO.
“Compliance equals security”Compliance is evidence against requirements; security also needs risk-based control effectiveness.

Performance-based task checklist

Before the exam, practice doing these quickly:

  • Select the best architecture control from business and threat cues.
  • Identify insecure configuration patterns: broad allow rules, public exposure, weak TLS, hard-coded secrets, excessive IAM permissions.
  • Map controls to zero trust, defense in depth, and least privilege.
  • Order incident response steps correctly.
  • Interpret logs and distinguish indicator, event, alert, incident, and breach.
  • Choose between SAST, DAST, IAST, SCA, fuzzing, and pen testing.
  • Prioritize vulnerabilities with business context, not severity alone.
  • Match IAM protocols to use cases.
  • Choose encryption, hashing, tokenization, masking, or signing correctly.
  • Apply RTO/RPO and risk formulas when numbers are provided.
  • Recommend compensating controls when ideal remediation is not immediately feasible.
  • Recognize when governance artifacts, risk acceptance, or vendor controls are required.

Final review sequence

  1. Review the official CompTIA SecurityX (CAS-005) objectives alongside this Quick Reference.
  2. Drill decision tables until you can explain why the best option is better than plausible distractors.
  3. Practice scenario and performance-based questions that require architecture selection, log interpretation, risk analysis, and incident response ordering.
  4. After each missed question, record the decision rule you failed to apply and retest with fresh original practice items.
Browse Certification Practice Tests by Exam Family