Systems Lifecycle Management practice questions

AWS CloudTrail

Why it fails: CloudTrail logs every action taken in the AWS account, providing the audit log required for change management.

AWS Shield

Why it fails: AWS Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS, making it tempting if the migration involved securing public-facing web applications against malicious volumetric attacks. However, it fails this scenario because it focuses entirely on network-layer security and threat mitigation rather than tracking infrastructure modifications. To satisfy the ISSMP mandate for auditing and change management history, an organisation must instead utilise a governance and logging service such as AWS CloudTrail or AWS Config, which records API activity and configuration changes across the AWS environment.

AWS Trusted Advisor

Why it fails: AWS Trusted Advisor focuses on evaluating existing cloud resources against operational excellence, cost optimisation, performance, and security best practices, rather than capturing an audit trail of infrastructure modifications. While it is tempting because security professionals frequently consult it for compliance checks and misconfiguration alerts, it would be the correct choice when a team needs automated recommendations to remediate resource wastage, security vulnerabilities, or service limit quotas across an account, rather than a chronological change management history.

Workflow Validators

Why it fails: Validators ensure that specific conditions, such as the presence of an approval comment or a specific flag, are met before a workflow transition occurs.

Issue Security Levels

Why it fails: Issue Security Levels restrict who can view specific tickets within a project, making them tempting if an administrator wants to hide pending changes from unauthorised users during the review cycle. However, this feature controls visibility rather than gating state transitions, meaning it cannot prevent a developer from merging code or resolving a Jira issue without formal CCB sign-off. Enforcing a mandatory approval workflow requires configuring Jira's workflow conditions and validators rather than altering ticket-level permissions.

Post-functions

Why it fails: Post-functions occur after the transition happens, which is too late to block an unauthorized change.

Memorandum of Understanding (MOU)

Why it fails: Although this document establishes a formal partnership and outlines general responsibilities, it fails this scenario because it lacks legally binding commitments and specific technical security controls necessary for system integration. It is tempting because organisations frequently use it to define broad scopes of cooperation and mutual goals prior to establishing a formal contract. It would be the correct choice when two independent entities need to document a shared understanding of a collaborative project or non-commercial initiative without enforcing strict operational mandates.

Service Level Agreement

Why it fails: A Service Level Agreement focuses exclusively on operational metrics, uptime guarantees, and support response times rather than mandating technical security baselines or access controls. It is tempting because vendor integrations often require formal contracts governing the partnership, and practitioners frequently confuse operational commitments with security policies. This document would be the correct choice if the question asked to define the guaranteed availability percentage or financial penalties associated with downtime for the third-party integration.

Acceptable Use Policy

Why it fails: An Acceptable Use Policy fails this scenario because it regulates employee conduct and resource usage rather than technical integration controls. It is tempting because it governs external entities interacting with corporate infrastructure, making it the correct choice for defining permitted user behaviour, device handling, and internet usage rules for internal staff and contractors.

Remove all access and require developers to submit tickets for DBAs to perform changes.

Why it fails: Removing all developer access creates a bottleneck that prevents timely incident resolution, failing the requirement for effective troubleshooting. While this approach enforces strict separation of duties and satisfies the principle of least privilege in high-security environments, it ignores the operational necessity for developers to diagnose production issues. This strategy is suitable for rigid, non-agile environments where production stability is prioritised over rapid debugging, but it lacks the granular, time-bound access controls required to maintain both security and system availability.

Create a shared 'admin' account for all developers.

Why it fails: Shared accounts prevent individual accountability, making it impossible to audit specific actions taken by developers within the production database. While this approach simplifies credential management in isolated, non-production laboratory environments where identity tracking is not a regulatory requirement, it violates the principle of non-repudiation. Organisations should instead implement just-in-time access via Microsoft Entra ID, ensuring each developer uses a unique, logged identity to perform troubleshooting tasks, thereby maintaining a clear audit trail of all database modifications.

Only allow access during business hours.

Why it fails: Restricting administrative access to business hours fails to address the fundamental security risk of excessive privilege, as developers retain full database control regardless of the time. This approach merely limits the window of opportunity for unauthorised actions rather than enforcing the principle of least privilege. Time-based access controls are designed for temporary, just-in-time elevation scenarios where a user requires elevated rights for a specific, time-bound task, such as when using Microsoft Entra ID Privileged Identity Management to mitigate persistent administrative exposure.

Number of servers decommissioned.

Why it fails: Decommissioning legacy servers measures infrastructure lifecycle management and the reduction of an organisation's overall attack surface, rather than evaluating security integration within software development. This metric is tempting because it tracks tangible risk reduction through the elimination of obsolete hardware, making it a valid Key Performance Indicator for IT asset management, data centre consolidation, or infrastructure modernisation initiatives.

Number of lines of code written.

Why it fails: Quantity of source code generated measures developer output and feature velocity rather than security efficacy or vulnerability density. While this metric is tempting for managers attempting to quantify team productivity or project scope during software delivery, it evaluates raw engineering scale rather than secure development practices. It remains a standard operational metric when estimating resource consumption, sprint velocity, or project estimation, but it fails to indicate whether the resulting software is hardened against potential exploits.

Number of developers hired.

Why it fails: Headcount metrics measure organisational growth and resource allocation rather than security integration quality, failing to reflect how effectively vulnerability management or threat modelling occurs during code creation. This metric is frequently tracked by human resources to monitor team scaling and project capacity, making it a valid indicator when planning operational budgets or staffing capacity for software development lifecycles, but completely unrelated to security posture.

Better developer morale

Why it fails: Developers often experience higher stress when forced to refactor production code due to late-found security issues.

Automatic regulatory compliance

Why it fails: Automated compliance tools function as continuous monitoring mechanisms rather than foundational security requirements, meaning they cannot retroactively fix architectural flaws introduced by failing to integrate security during the initial requirements phase. This option appears tempting because organisations often leverage automated governance, risk, and compliance platforms to streamline reporting and audit preparation. Such tools provide value when integrated into an established, secure development lifecycle to validate existing controls, but they cannot replace the necessity of embedding security mandates into the project's foundational requirements.

Faster deployment velocity

Why it fails: While it might seem faster initially, the technical debt caused by later remediation actually slows down the lifecycle long-term.

Use the storage array's built-in secure erase function for the RAID array, and rely on the DR site's replication deletion to remove all copies.

Why it fails: The built-in secure erase may not work consistently across all drive types in a RAID array, and it may not cover data in cache or spare drives. Relying solely on replication deletion at the DR site is risky because snapshots or backups may persist. This approach lacks verification and does not ensure that all PII copies are sanitized, leaving a compliance gap.

Overwrite the RAID array with a single pass of zeros, and delete the replicated data at the DR site using the storage array's management interface.

Why it fails: A single-pass overwrite may not sanitize all sectors on a RAID array, especially with wear leveling on SSDs or if the array uses self-encrypting drives. Deleting replicated data via a management interface often does not securely erase it from all disks or snapshots at the DR site. This approach leaves PII potentially recoverable and does not meet the stringent requirements for decommissioning PII.

Shred the physical server's hard drives and obtain a certificate of data destruction for the backup tapes from the tape vendor.

Why it fails: Shredding drives is effective but may be unnecessary if cryptographic erasure is possible, and it does not address the replicated data at the DR site. A certificate from the tape vendor may not cover tapes already in the organization's possession. This option overlooks the DR replication and assumes tapes are vendor-managed, which is not stated. It is incomplete for ensuring no PII remains.

Require developers to run a local scanning tool on their workstations and attach the scan report to the pull request before merging.

Why it fails: Local scanning depends on individual developers using the correct tool version and configuration, and a report attached to a pull request is a self-declaration that can be stale or fabricated. It is not enforced by the pipeline, so a merge can proceed without a genuine scan. This relies on human discipline rather than an automated control that guarantees the artifact is clean.

Enable immutable tags on the production registry so that an existing image tag cannot be overwritten with different content after it is pushed.

Why it fails: Immutability protects tag integrity and prevents accidental or malicious overwrites, which is valuable for reproducibility, but it does nothing to evaluate whether the image content is vulnerable. A cleanly signed, immutable image can still contain a critical CVE. It addresses a different risk than the one in the objective, so it does not prevent vulnerable images from reaching production.

Configure the production registry to send an alert to the security team whenever an image containing critical vulnerabilities is pulled by a running pod.

Why it fails: Alerting after a vulnerable image has already been pulled and is running in production is detective, not preventive. By the time the notification is generated the workload may already be exposed, and response depends on human action. The stated objective is to prevent vulnerable images from reaching the production registry, so a post-deployment alert does not satisfy it.

The ISSMP personally reviewing every SQL script.

Why it fails: Separation of Duties requires different people to author, test and approve changes; one person reviewing their own scripts concentrates control rather than dividing it. It is tempting because review is a genuine control activity, but it would be correct only when the reviewer is independent of the script author.

Allowing the automated CI/CD tool to deploy without human review.

Why it fails: Relying entirely on an automated CI/CD pipeline to push schema changes directly to production lacks the independent human authorisation required to enforce separation of duties, as no single administrator or security officer verifies the staging test results before deployment. Such pipelines are designed to accelerate continuous delivery and eliminate manual bottlenecks by executing predefined build and deployment scripts automatically. This hands-free automation is the correct choice in low-risk, high-frequency development environments or routine code deployments where formal dual-control change management gates are intentionally bypassed for operational speed.

Having the DBA perform the deployment in staging and production.

Why it fails: Allowing the same database administrator to execute schema deployments across both staging and production violates the principle of separation of duties by centralising complete authority over both environments into a single role, creating an unchecked path for unverified alterations. This approach is tempting because consolidating operational responsibilities streamlines routine maintenance tasks and accelerates deployment velocity. It would represent the correct choice in highly resource-constrained environments where strict segregation between administrative tiers is operationally unfeasible, or during emergency break-glass procedures where standard multi-person authorisation workflows must be bypassed to restore critical production services.

To automate the removal of legacy hardware.

Why it fails: Security gates function as mandatory validation checkpoints within the software development lifecycle to ensure code meets predefined security standards before progressing to the next stage. Automating hardware decommissioning relates to infrastructure lifecycle management or asset disposal policies rather than software quality assurance. This option appears attractive because organisations frequently seek to automate routine operational tasks, making it a valid objective for IT asset management frameworks or data centre migration projects where legacy hardware removal is a primary requirement.

To stop all software development until the budget is approved.

Why it fails: Security gates function as technical checkpoints to validate security requirements, such as vulnerability scanning or compliance audits, rather than acting as administrative financial controls. While budget approval represents a valid project management milestone for project initiation or resource allocation, it lacks the technical verification mechanism required to assess code integrity or software security posture. Confusing fiscal governance with technical assurance misidentifies the gate’s role in mitigating software vulnerabilities during the build process, which is the primary objective specified in the stem.

To provide a location for developers to submit their resignation.

Why it fails: Security gates function as formal checkpoints within the software development lifecycle to validate that mandatory security requirements are met before code progresses to the next phase. This option confuses an administrative control point with human resources procedures, which fall outside the scope of technical vulnerability management. While offboarding processes are necessary for maintaining organisational security, they relate to identity lifecycle management—such as revoking access via Microsoft Entra ID—rather than the automated quality assurance and compliance verification processes inherent to SDLC security gates.

Acceptable Use Policy (AUP)

Why it fails: An Acceptable Use Policy defines the behavioural expectations and usage constraints for personnel interacting with organisational assets, rather than specifying the technical security controls required for a system’s architecture. This document is tempting because it forms a foundational component of organisational governance; however, it applies to end-user conduct rather than the security requirements engineering process. It would be the correct choice if the question asked for the document that mandates how employees must interact with corporate resources to maintain compliance.

Service Level Agreement (SLA)

Why it fails: Service Level Agreements define the performance expectations and availability metrics for a service provider rather than specifying the technical security controls required for system development. While they are essential for establishing operational accountability and uptime guarantees between a customer and a vendor, they lack the granular security requirements necessary for the SDLC. They represent a contractual commitment to service quality rather than the internal security architecture or compliance mandates that must be documented during the initial requirements phase.

Business Impact Analysis (BIA)

Why it fails: A Business Impact Analysis focuses on quantifying the operational and financial consequences of system disruption to determine recovery time objectives. While it informs the requirements phase by establishing availability needs, it does not define the technical security controls themselves. Candidates often confuse this with security documentation because both activities occur early in the SDLC; however, the BIA serves as a prerequisite for business continuity planning rather than a repository for specific security control implementation requirements.

Mandate that the project manager create a manual SRTM separately from the development tasks.

Why it fails: Mandating a manual SRTM creates an administrative silo that disconnects security oversight from the iterative development lifecycle, violating the Agile principle of integrated delivery. While this approach appears to ensure rigorous compliance by maintaining a traditional audit trail, it is only valid in strictly regulated waterfall environments where documentation must exist independently of the codebase. In an Agile transition, this method forces the team to perform redundant work, failing to embed security requirements directly into the product backlog as actionable user stories.

Deny the transition until full waterfall documentation is restored.

Why it fails: Mandating the restoration of waterfall documentation directly contradicts the Agile manifesto’s preference for working software over comprehensive documentation, effectively stalling the transition and ignoring the team's shift toward iterative delivery. This approach is tempting in highly regulated environments where strict compliance frameworks require a formal SRTM to demonstrate auditability and traceability for every security control. It remains the correct choice only when contractual obligations or rigid industry standards explicitly forbid the use of lightweight artefacts like user stories for security assurance.

Allow the team to omit security requirements to speed up deployment.

Why it fails: Omitting security requirements violates the fundamental principle of security by design, as it leaves the system vulnerable to unmitigated threats and regulatory non-compliance. While prioritising speed and agility is a common objective in rapid development cycles, this approach is only valid when security controls are integrated directly into the backlog or automated testing frameworks rather than being abandoned entirely. Bypassing these safeguards creates an unacceptable risk posture that fails to satisfy the governance and accountability requirements inherent in the ISSMP role.

Decommissioning phase

Why it fails: SAST must run during coding and build stages, where source is available and defects are cheap to fix; decommissioning occurs after the system is retired, when no code is being produced. The phase is tempting because security checks are expected late in assurance, but static analysis requires source code that no longer changes.

Post-deployment monitoring

Why it fails: Executing Static Application Security Testing during post-deployment monitoring occurs far too late in the DevOps lifecycle, failing the requirement to identify vulnerabilities early because the code is already running in production. This stage is tempting because teams rely on it to observe runtime behaviour, detect live threats, and capture anomalous traffic patterns. It would be the correct choice when validating operational infrastructure hardening, performing dynamic penetration testing, or configuring runtime application self-protection mechanisms against active attacks.

Requirements gathering phase

Why it fails: Static Application Security Testing tools analyse source code or compiled binaries, which do not exist during the requirements gathering phase when only abstract business needs and functional specifications are documented. This option is tempting because early security integration is a core objective of DevSecOps, and defining security criteria during requirements analysis is vital for establishing compliance baselines. It would be the correct choice if the question asked when to define high-level security use cases, threat models, and regulatory constraints before any coding or pipeline implementation begins.

Regular penetration testing

Why it fails: Penetration testing identifies exploitable weaknesses at a point in time; it does not enforce or continuously reconcile configuration state across clusters. It is tempting because it validates real-world exposure, and it would be the right choice when the goal is to discover unknown vulnerabilities rather than apply baseline settings uniformly.

Manual code review of Dockerfiles

Why it fails: Reviewing Dockerfiles inspects image build instructions, not the running cluster's admission, RBAC or pod-security configuration, so drift across clusters persists. It is tempting because it catches insecure base images and build practices, and it would be correct when the objective is hardening image construction rather than enforcing cluster-wide policy.

Role-Based Access Control (RBAC) only

Why it fails: RBAC governs who may perform actions on Kubernetes resources; it cannot enforce pod security settings such as privileged containers or host mounts. It is tempting because RBAC is a core cluster control, and it would be correct when the requirement is restricting user and service account permissions rather than configuration compliance.

Manual Terraform code review logs.

Why it fails: Manual review logs are retrospective human records and cannot automatically block a pipeline before an insecure Terraform plan applies. They suit audit evidence and change accountability. Preventing deployment requires automated policy-as-code scanning, such as Checkov or OPA, gating the CI/CD stage.

Using AWS IAM policies only.

Why it fails: Relying exclusively on AWS IAM policies fails because access control lists and permission boundaries regulate who can perform operations, whereas Infrastructure-as-Code security scanning requires static analysis of resource attributes, such as verifying whether an Amazon S3 bucket's public access block is explicitly enabled prior to deployment. This approach remains tempting because IAM policies form the cornerstone of cloud authorisation and cloud security governance, making them the correct choice when enforcing the principle of least privilege for runtime identities and API actions against existing cloud infrastructure.

Disabling the Terraform 'plan' command.

Why it fails: Removing the `plan` phase eliminates the crucial dry-run mechanism that allows engineers to preview resource alterations and catch unintended modifications before deployment, meaning this approach fails to proactively inspect code for security compliance. This measure is typically tempting as a way to streamline pipeline velocity by cutting out redundant execution steps, and it would be the correct choice when transitioning to an ephemeral deployment model where intermediate validation is intentionally handled by out-of-band monitoring agents rather than synchronous pipeline gates.

Hardcoding API keys into environment variables.

Why it fails: Hardcoding API keys creates static, long-lived credentials that lack the dynamic rotation and granular identity verification required for mutual TLS or service mesh architectures. While developers often use environment variables for local configuration or simple proof-of-concept prototypes to inject secrets without modifying source code, this approach fails to provide the automated, short-lived token issuance provided by Microsoft Entra ID. Relying on static keys exposes the infrastructure to significant risk if a single service is compromised, as the credentials remain valid until manually revoked.

Installing an antivirus agent on every container.

Why it fails: Antivirus agents monitor file system integrity and detect malicious payloads, but they provide no mechanism for establishing mutual TLS or cryptographic identity verification between network endpoints. While these agents are essential for identifying malware threats on host operating systems or persistent container storage, they do not facilitate the service-to-service authentication or traffic encryption required by the prompt. Implementing a service mesh or mutual TLS protocol is necessary to secure the communication channels themselves, rather than scanning the individual container binaries for signature-based threats.

Using a standard VPN between all services.

Why it fails: Implementing a VPN between every individual microservice creates an unsustainable network topology, as the overhead of managing thousands of point-to-point tunnels prevents granular service-to-service authentication. While VPNs effectively secure transit across untrusted wide area networks by establishing encrypted tunnels between distinct network segments, they operate at the transport layer. This approach lacks the identity-based granularity required to verify specific service identities, whereas a service mesh or mutual TLS architecture provides the cryptographic identity verification necessary for modern distributed service communication.

Archiving the data to unencrypted tape drives.

Why it fails: Storing sensitive information on unencrypted media directly violates GDPR mandates regarding data protection and confidentiality. While archiving serves as a legitimate long-term retention strategy for regulatory compliance or historical record-keeping, it requires robust encryption at rest to maintain security. This approach is only viable when the storage medium incorporates cryptographic controls to prevent unauthorised access, ensuring that decommissioned data remains protected throughout its lifecycle rather than becoming a significant liability for the organisation.

Notifying all third-party vendors.

Why it fails: Notifying vendors fails to address the primary regulatory mandate of data destruction, which requires the permanent erasure or anonymisation of personal information stored within the decommissioned system. While vendor communication is a standard procedural step for managing supply chain risk and terminating service level agreements, it does not sanitise the data itself. This action is necessary when managing third-party access rights or offboarding cloud services, such as revoking enterprise application permissions within Microsoft Entra ID, but it remains secondary to ensuring data privacy compliance.

Deleting the source code repository.

Why it fails: Deleting the source code repository fails to address the actual data privacy requirements because it does not sanitise the production databases or persistent storage volumes where sensitive personal information resides. While removing source code is a standard security practice during the final stages of a software development lifecycle to prevent intellectual property theft or the exposure of hardcoded credentials, it does not fulfil the legal obligation to purge or anonymise user data stored within the application's operational environment.

Rewrite the application code personally.

Why it fails: Personally rewriting code falls outside the governance and risk management remit of an Information Systems Security Management Professional (ISSMP), whose role requires overseeing security policy enforcement rather than executing direct software engineering tasks. This approach can be tempting during urgent operational gridlock because manual code remediation directly resolves underlying vulnerabilities without deploying unstable third-party patches. Such hands-on refactoring would be the correct choice in a dedicated application development scenario where the security manager holds direct programming accountability and possesses the requisite source-code access and authorship privileges to safely implement custom logic changes.

Ignore the finding as it is non-critical.

Why it fails: Dismissing a vulnerability finding simply because it is labelled non-critical violates standard risk management frameworks, which mandate formal evaluation and tracking of all known flaws regardless of severity. This approach appears tempting when dealing with minor or low-risk alerts where mitigation overhead outweighs the potential impact, making blanket dismissal an efficient triage shortcut for overwhelmed operational teams. Such a strategy would only be appropriate if a formal vulnerability assessment verified the finding as an invalid false positive or if the underlying asset was permanently decommissioned, neither of which applies here given the acknowledged existence of a functional patch.

Force the patch regardless of impact.

Why it fails: Enforcing the patch immediately without application testing guarantees severe operational disruption and potential business downtime, directly violating the primary governance duty to balance security risk with enterprise availability. This heavy-handed enforcement is tempting because it closes the vulnerability and satisfies strict compliance frameworks, making it the correct choice when addressing critical-severity internet-facing zero-day exploits where immediate containment of an active breach outweighs collateral application stability.

Release phase

Why it fails: Waiting until the release phase occurs far too late in the development lifecycle to introduce threat modelling, as architectural flaws and design vulnerabilities become exponentially more expensive and difficult to remediate once code has already been compiled for deployment. This stage appears attractive because final security validation and penetration testing naturally occur immediately prior to production rollout, making it the correct choice for executing dynamic vulnerability scans, final compliance audits, and black-box testing against the fully assembled application package.

Operations and Maintenance

Why it fails: Conducting threat modelling during the operations and maintenance phase arrives far too late to cost-effectively remediate architectural flaws, as the software is already deployed in production. This phase is tempting because continuous threat modelling is genuinely required here to validate security controls against newly discovered zero-day exploits and evolving attacker tactics. Consequently, it would be the correct choice when performing periodic security reviews, assessing post-deployment configuration drift, or evaluating the risk impact of live infrastructure modifications and subsequent patch management cycles.

Initiation phase

Why it fails: Conducting a formal threat modelling session during the initiation phase fails because system architecture, data flows, and technical specifications have not yet been defined, leaving insufficient detail to systematically identify vulnerabilities or map trust boundaries. This phase is tempting because security should be integrated as early as possible in the software development lifecycle; it serves its intended purpose during high-level project conception to establish preliminary business cases, secure initial stakeholder buy-in, and define high-level security objectives before technical design begins.

Encrypting the entire source repository.

Why it fails: Encrypting the repository protects data at rest but does not verify who authored a change or detect tampering after commit. Code signing, using cryptographic signatures verified in the pipeline, is required. Repository encryption suits confidentiality of stored source, not build integrity assurance.

Using HTTPS for all internal traffic.

Why it fails: Securing transport channels via HTTPS only protects data in transit against interception and eavesdropping during deployment, failing to provide the cryptographic integrity and non-repudiation required to verify that source code has not been tampered with post-compilation. This mechanism is tempting because it forms a standard baseline control for safeguarding internal microservice communications and API payloads, making it the correct choice when mitigating network sniffing risks between distributed build nodes rather than validating artifact authenticity.

Running the build on a dedicated hardened server.

Why it fails: Hardening the build environment mitigates the risk of unauthorized infrastructure modification and safeguards build secrets, but it fails to address code tampering because it lacks cryptographic artifact signing capabilities. This approach is tempting as a foundational security measure for continuous integration pipelines, and it would be the correct choice when aiming to prevent build runner compromise and secure the compute environment where compilation takes place, yet it does not generate verifiable digital signatures for the final deployment packages.