Secure Software Deployment Operations And Management practice questions

Upgrade the SSL/TLS certificate to a higher bit-length.

Why it fails: Upgrading the certificate does not fix insecure cryptographic usage within the application code.

Enable HTTP/2 protocol enforcement on the WAF load balancer.

Why it fails: Protocol enforcement does not address application-level cryptographic vulnerabilities.

Disable the WAF's logging feature to improve response time during the incident.

Why it fails: Disabling logging hinders forensic analysis and incident response.

Hardcode the credentials in the application code and use AWS KMS to encrypt the binary at rest.

Why it fails: Hardcoding credentials is a security anti-pattern, regardless of disk encryption.

Use the Elastic Beanstalk Console to set plain-text environment properties.

Why it fails: Plain-text environment variables are visible to anyone with console access.

Store credentials in the .ebextensions/environment.config file with read-only permissions.

Why it fails: Config files are stored in source control and are not suitable for sensitive secrets.

Immediately shut down the Blue environment to save costs.

Why it fails: Shutting down too early prevents an immediate rollback if the Green environment fails.

Update the load balancer configuration to point to both environments simultaneously.

Why it fails: This defeats the purpose of the traffic switch and may expose users to an unverified environment.

Ensure both environments use the same shared database instance.

Why it fails: Shared databases can lead to data corruption or cross-contamination during the transition.

An increase in the number of developers logged into the system.

Why it fails: Developer login activity is generally unrelated to external DoS attacks.

A decrease in CPU utilization across all servers.

Why it fails: Falling CPU utilisation suggests idle or failed servers, not the resource exhaustion a DoS produces; saturation, not decline, is the signal. It is tempting because outages can drop traffic, but monitoring latency, traffic and error rates reveals the attack.

A reduction in database write operations.

Why it fails: Database write volume is not one of the four Golden Signals (latency, traffic, errors, saturation), and a DoS flood typically leaves writes untouched or queued behind connection exhaustion. Write-rate monitoring is genuinely useful for detecting replication lag or storage saturation, which is a different scenario from volumetric attack detection.

Run the Java application as the root user to ensure all permissions are available.

Why it fails: Running as root grants the JVM unrestricted filesystem and process access, directly contradicting the least-privilege goal, so any application compromise yields full host control. It is tempting because root removes permission-denied errors during deployment, yet a dedicated non-privileged service account is what actually constrains the runtime.

Disable the Java Virtual Machine's garbage collection to prevent memory-based attacks.

Why it fails: Garbage collection reclaims heap memory; disabling it causes memory exhaustion, not reduced permissions. It is tempting because limiting runtime capabilities sounds like hardening, and would be correct only if the goal were performance tuning, never least privilege.

Assign a public IP address to the application server to facilitate remote debugging.

Why it fails: A public IP exposes the debugging port to the internet, expanding the attack surface rather than limiting runtime permissions. It is tempting because remote debugging needs reachability, but that is achieved through a bastion host or VPN; the scenario concerns constraining the JVM's privileges, not network exposure.

Apply all schema migrations and application changes in a single atomic deployment step so the state is never partially updated.

Why it fails: Atomic deployment sounds appealing but is impractical across application code and database schema, which have separate lifecycles and cannot be committed together transactionally. If the combined step fails midway, the team faces an inconsistent state that is harder to reverse. This practice increases rollback risk rather than reducing it and does not guarantee reversibility for the e-commerce application.

Take a full database backup immediately before every deployment and restore it if the release fails.

Why it fails: Restoring a full backup discards all transactions committed since the backup, causing data loss for an active e-commerce site, and restoration can take far longer than the acceptable outage window. It also does not address application-level compatibility with the schema. While backups are essential for disaster recovery, they are not a safe or timely rollback mechanism for routine failed deployments.

Schedule rollbacks only during the nightly maintenance window to avoid impacting live customer sessions.

Why it fails: Restricting rollbacks to a nightly window delays recovery for hours, extending customer impact and revenue loss for a high-traffic e-commerce site. It also forces teams to keep a broken release live until the window opens. This is an operational scheduling choice, not a technical practice that makes rollback safe, so it does not meet the requirement for reliable reversal.

Clear the application's cache to remove any temporary sensitive data.

Why it fails: Clearing the cache removes temporary copies but leaves the exposed environment variables themselves valid, so the attacker retains working credentials. Cache clearing suits stale-data or session-hygiene tasks; the immediate requirement here is rotating every credential the environment variables held.

Increase the logging level to 'DEBUG' to track the attacker's actions.

Why it fails: Raising logging to DEBUG improves visibility into attacker activity but does nothing to the credentials the attacker already holds, and verbose logs may capture further secrets. Debug logging belongs to the investigation and evidence-gathering phase, not to the immediate containment step of rotating exposed credentials.

Re-deploy the application using the same configuration to ensure a clean state.

Why it fails: Redeploying with the same configuration reinstates the identical compromised credentials, so the attacker's access persists. A clean redeploy is useful after the secrets have been rotated and the exposure vector patched, but it is not itself a credential-management response to disclosure.

Check the file timestamp using the operating system's file system metadata.

Why it fails: File timestamps are trivially altered and reflect only the last write, not the signer's content hash, so tampering goes undetected. Timestamps suit forensic timeline reconstruction or cache validation, where change ordering matters rather than cryptographic provenance.

Upload the artifact to a public VirusTotal scan before deploying.

Why it fails: VirusTotal reports malware detections across engines; it neither recomputes the build system's signature nor binds the artifact to its signer, so a modified binary can still scan clean. Public scanning suits reputation triage of unknown samples, not deployment integrity verification.

Compare the file size of the artifact with the size listed in the manifest file.

Why it fails: File size comparison cannot detect tampering, since altered content can preserve byte length; only a cryptographic hash or signature verification proves integrity. It is tempting because manifests list sizes, and size checking would be correct for detecting truncated or incomplete downloads, not deliberate modification.

Enable the Kubernetes Audit Log and monitor for kubectl exec commands.

Why it fails: Audit logging records API activity such as kubectl exec; it observes behaviour after the fact and enforces nothing. It is tempting because auditing is a core detection control, and it would be correct for investigating who ran commands in a cluster, not for blocking unauthorised outbound connections from a pod.

Configure PodSecurityPolicies to restrict the containers to non-root users.

Why it fails: PodSecurityPolicies govern pod privilege and security context, not network reachability, so they cannot restrict egress to authorised endpoints. They are tempting because they harden container runtime behaviour, and would be correct when the requirement is preventing containers running as root or with elevated capabilities.

Install a Service Mesh like Istio to enforce mTLS.

Why it fails: Istio's mTLS authenticates service-to-service identities but does not by itself restrict egress to known external endpoints; that requires egress controls such as NetworkPolicy or a service mesh egress gateway. It is tempting because service meshes handle east-west traffic security, and Istio would be correct for encrypting and authenticating internal pod-to-pod communication.

Reducing the total cost of ownership of the cloud infrastructure.

Why it fails: Secure configuration management addresses hardening baselines, drift detection and least privilege; cost reduction is a financial outcome of cloud governance and rightsizing, not a security objective. It tempts because standardised, automated configuration does incidentally lower operational spend, but that benefit is a by-product rather than the control's purpose.

Ensuring that developers have administrative access to production databases.

Why it fails: Granting developers administrative access to production databases removes separation of duties and widens the attack surface, directly opposing secure configuration management's goal of hardened, least-privilege baselines. It tempts because developers sometimes need elevated rights in isolated development or test environments, but production access is precisely what the control restricts.

Maximizing the number of features delivered in each release.

Why it fails: Secure configuration management governs baseline hardening, change control and drift detection; feature throughput is a product-delivery metric unrelated to security posture. It tempts because disciplined configuration pipelines can speed releases, yet maximising feature count is a release-management aim, not the objective of securing configurations.

Configure a post-deployment notification to Slack using a webhook.

Why it fails: A Slack webhook only notifies people after deployment; it performs no scanning and cannot prevent a vulnerable image reaching production. Notification is tempting because it provides visibility into pipeline outcomes, and would be correct when the requirement is to alert the team about build or deployment status.

Manually verify image signatures using Docker Content Trust after deployment.

Why it fails: Docker Content Trust verifies image signatures, not vulnerabilities, and runs after deployment rather than before promotion, so it cannot block a vulnerable image entering production. It is tempting because it is a genuine supply-chain control, and would be correct when the requirement is to confirm image integrity and publisher authenticity.

Enable Jenkins 'Build periodically' to scan images in the registry.

Why it fails: Periodic builds scan on a schedule, so images can be promoted to production between runs; scanning must gate the pipeline before promotion. Scheduled scanning is tempting because it continuously re-checks the registry, and would be correct for detecting newly disclosed vulnerabilities in already-deployed images.

Rename the state file to 'secret.tfstate' to hide it from attackers.

Why it fails: Renaming the state file provides no access control; the file still holds plaintext resource attributes and secrets, and obscurity does not prevent reads. It is tempting because hiding filenames feels like hardening, but the actual control is remote encrypted backend storage with restricted IAM and state locking.

Store state files in a version-controlled Git repository for change tracking.

Why it fails: Git tracks plaintext state, exposing secrets and resource attributes to anyone with repository access; state also contains sensitive outputs that version control cannot encrypt. Remote backends with encryption and locking are required. Git suits versioning Terraform configuration code, not state, which needs access controls and locking to prevent concurrent corruption.

Manually delete the state file after every Terraform apply command.

Why it fails: Deleting state destroys Terraform's record of managed resources, so subsequent plans cannot map configuration to real infrastructure and may duplicate or orphan resources. State must persist between runs. Manual deletion suits one-off teardown of disposable sandboxes, not ongoing secure configuration management.

Run all build processes in an isolated network segment without internet access.

Why it fails: Isolating builds from the internet blocks public registry access entirely, which breaks legitimate dependency downloads rather than resolving internal names first. It is tempting as a containment measure, and suits air-gapped environments, but the scenario requires builds that still consume approved packages, so name-resolution precedence must be configured instead.

Use only open-source software libraries.

Why it fails: Restricting builds to open-source libraries does not prevent dependency confusion; public registries are themselves open source, so an attacker can still publish a higher-versioned package matching an internal name. It is tempting as a licensing or provenance policy, and suits reducing proprietary risk, but it does not control package resolution.

Regularly scan the public registries for malicious packages.

Why it fails: Scanning public registries detects known malicious packages after publication but does not stop a build resolving an internal package name to a higher-versioned public one. It is tempting as a monitoring control, and suits threat-intelligence hygiene, yet it leaves the version-resolution mechanism that causes dependency confusion untouched.

To act as a backup for the main container if it crashes.

Why it fails: Sidecars run alongside the main container and terminate with it, so they provide no crash failover. It is tempting because they share the pod, and a ReplicaSet or multi-container redundancy pattern would be correct when the requirement is automatic restart or replacement of a failed container.

To provide additional CPU and memory resources to the main container.

Why it fails: Sidecars add proxying and policy enforcement, not CPU or memory allocation, which comes from the pod's resource requests and limits. It is tempting because sidecars consume pod resources, and raising those requests would be correct when the main container is being throttled or evicted.

To store persistent data for the main application.

Why it fails: Sidecars intercept and proxy network traffic for security, observability and routing; they do not persist application data. It is tempting because sidecars share the pod's lifecycle and volumes, and a persistent volume claim would be correct when the main container needs durable storage across restarts.

A list of all developers who worked on the release.

Why it fails: Developer attribution is release metadata, not a deployment control; it neither secures the release nor gates its promotion. It is tempting because accountability and audit trails matter in secure development, but that belongs to change records or provenance tracking, not the deployment plan's security mechanisms.

A plan for decommissioning all previous versions of the software.

Why it fails: Decommissioning old versions is lifecycle retirement, not part of deploying the new release securely. It is tempting because removing vulnerable legacy instances reduces exposure, but that is a separate retirement activity; a secure deployment plan covers authorisation, integrity verification and rollback of the release being installed.

An automated script that changes the administrator password on every server.

Why it fails: Blanket password rotation across every server is unrelated to deploying the release securely and risks locking out service accounts. It is tempting because credential hygiene supports security generally, but that is ongoing privileged-access management; a deployment plan addresses artefact integrity, approvals and rollback for the software being released.

Store all application logs in a publicly accessible S3 bucket for easy debugging.

Why it fails: A publicly accessible bucket exposes log contents to anyone, including credentials, tokens and internal topology, defeating the confidentiality logging must preserve. It is tempting because centralised object storage genuinely suits aggregation and debugging, and would be correct if the bucket were private with strict IAM policies and encryption.

Delete all logs after 24 hours to ensure compliance with the Right to be Forgotten.

Why it fails: Retaining logs for investigation and audit is a core security requirement, so deleting them after 24 hours destroys the evidence trail needed for incident response and forensic analysis. It is tempting because data-minimisation and storage-limitation principles do exist, and deletion would be correct where logs contain personal data no longer lawfully needed.

Increase the log verbosity to the maximum level in production indefinitely.

Why it fails: Maximum verbosity indefinitely floods logs with noise, inflates storage cost and risks writing sensitive data into aggregators, weakening rather than strengthening security. It is tempting because more detail appears safer, but high verbosity is correct only for short, targeted troubleshooting windows, not sustained production logging.

Embed hardcoded credentials for the database in the build artifact to ensure connectivity.

Why it fails: Hardcoded database credentials inside the artefact leak to anyone who obtains the build, cannot be rotated without rebuilding, and violate secrets-management requirements. Injecting credentials at runtime from a vault or environment configuration is the correct approach; embedding suits only isolated local test fixtures with non-production data.

Bypass unit tests to speed up the deployment pipeline.

Why it fails: Skipping unit tests removes the verification gate that catches regressions and security-relevant defects before artefacts ship, so the build cannot be trusted as production-ready. It tempts teams chasing faster pipelines, and would suit throwaway prototypes or local development builds where no release approval or integrity evidence is required.

Compile the code with debugging symbols enabled for easier production troubleshooting.

Why it fails: Debug symbols expose internal function names, paths and memory layout in the shipped binary, giving attackers reconnaissance material and enlarging the artefact. They are genuinely useful for diagnosing crashes in pre-production or staging environments, but production builds should be stripped or symbols stored separately.

Disabling all automated deployment pipelines.

Why it fails: Disabling pipelines removes the automated, repeatable enforcement that keeps environments consistent, so drift increases as manual changes accumulate. It is tempting because pipelines can propagate a bad configuration, but the correct drift-reduction scenario is controlled, versioned pipeline deployment with approvals, not abandoning automation.

Allowing manual configuration changes via the SSH console.

Why it fails: Manual SSH changes bypass version control and review, so each host diverges from the declared baseline and drift grows. It is tempting because direct console access helps urgent break-fix work, but it is the correct choice only in an incident-response context, not as a standing configuration management practice.

Share all internal server IP addresses in the public DNS records.

Why it fails: Publishing internal server IP addresses in public DNS exposes the application's internal topology to attackers, enabling direct targeting and bypassing perimeter controls. DNS records exist to resolve names to addresses for legitimate clients, so public records suit internet-facing services only. Internal addressing belongs in split-horizon or private zones, never in publicly resolvable records.

Permit all inbound traffic on port 80 to ensure maximum availability.

Why it fails: Permitting all inbound port 80 traffic removes filtering, so monitoring cannot detect or block malicious requests. It is tempting when availability is prioritised, but a web application firewall with logging would be the correct monitoring control.

Disable all egress traffic from the application servers to prevent data exfiltration.

Why it fails: Disabling all egress traffic breaks the application's legitimate outbound dependencies, such as database replication, API calls and patch downloads, so it cannot function. It is tempting because egress filtering genuinely blocks command-and-control and exfiltration channels, and would suit a strictly isolated, no-outbound-connectivity workload rather than a normal operational application.

Granting 'Admin' privileges to all developers on the CI/CD server.

Why it fails: Admin rights on the CI/CD server let any developer alter pipeline definitions, credentials and build agents, defeating segregation of duties. It is tempting because broad access removes friction when engineers need to debug failed builds, and least privilege is the actual control required.

Storing pipeline secrets in plain text within the Jenkinsfile.

Why it fails: Plain-text secrets in a Jenkinsfile are readable by anyone with repository access and persist in commit history. It is tempting because inline values are the quickest way to get a pipeline running, whereas a secrets manager injects credentials at runtime without storing them in source.