S2000-023 Technical Solution Design

Technical Solution Design Detailed Explanation

1. Reference Architectures

Reference architectures are high-level blueprints created by IBM to show customers how to design regulated workloads correctly.
They are aligned with the IBM Cloud Framework for Financial Services, which means they already incorporate the necessary security and compliance controls.

You can think of them as:

“Pre-approved design patterns”
for regulated workloads on IBM Cloud.

There are three main reference architectures you must understand.

1.1 VPC-based architecture

This is the most common architecture for financial workloads.

It uses:

• IBM Cloud VPC (Virtual Private Cloud)

• Virtual Server Instances (VSIs)

• Red Hat OpenShift clusters (if using containers)

1.1.1 What problems does this architecture solve?

Financial institutions need:

• Strong network isolation

• Control over traffic

• Custom routing

• Secure subnets for different components

• Integration with on-prem systems

A VPC provides all of this.

1.1.2 Why VPC is suitable for regulated workloads

• Each VPC is logically isolated from others.

• You can create private subnets for sensitive systems.

• Security groups and ACLs support least-privilege connectivity.

• Flow Logs, Activity Tracker, and IAM policies support audit and compliance.

• OpenShift clusters running inside the VPC allow cloud-native workloads with security built-in.

In exam situations, when you see regulated workloads + cloud-native + IBM Cloud,
the answer is usually VPC-based architecture.

1.2 Satellite-based architecture

This architecture uses IBM Cloud Satellite.

Satellite lets IBM Cloud run services in:

• On-prem data centers

• Other clouds

• Edge locations

This is extremely useful when data residency or latency requirements prevent moving data to IBM Cloud regions.

1.2.1 Why Satellite is used

• Some regulators require:

  “Data must NOT leave the country / facility.”

• Some systems interact with ultra-low-latency networks (e.g., trading systems).

Satellite allows you to:

• Keep data local

• Deploy IBM Cloud services near the workloads

• Maintain compliance while using IBM Cloud capabilities

1.2.2 Typical Satellite use cases

• Local processing of regulated data

• Edge analytics

• Hybrid cloud designs

• Workloads with strict latency constraints

Whenever the exam mentions:

• “Data cannot leave the customer facility”

• “Must meet data residency rules”

• “Workload must remain close to on-prem systems”

→ the answer is often Satellite-based architecture.

1.3 VMware Regulated Workloads architecture

Many financial institutions still run large VMware environments.
Migrating them to containers is a long journey.

This architecture is designed for:

• VMware-based workloads

• That must run in regulated environments

• And need enhanced security and compliance

1.3.1 Why VMware regulated workloads exist

Financial institutions often have:

• Legacy systems

• Mainframe-connected VMs

• Proprietary applications

• Vendors who only support VMware

So IBM Cloud provides a secure, hardened VMware environment aligned with the Financial Services framework.

1.3.2 Key benefits

• Supports existing VMware tools and processes

• Adds hardening layers for compliance

• Integrates with FS controls (logging, encryption, IAM)

• Supports hybrid migration paths (vMotion, HCX)

In the exam:

If a question says the customer has large VMware estates, needs cloud migration, and must meet financial regulations,
the correct answer is often:

“IBM Cloud for VMware Regulated Workloads architecture.”

2. Secure Landing Zones

A landing zone is a foundational, pre-configured environment that follows best practices for security, networking, logging, and compliance.

Think of it as:

“A ready-made, secure cloud environment you deploy BEFORE running workloads.”

Landing zones are essential for regulated workloads because:

• They enforce consistent security controls

• They reduce the chance of misconfiguration

• They speed up cloud adoption

• They provide a standard pattern for audits

2.1 Landing Zone for OpenShift – Financial Services edition

This is a special version of a landing zone tailored for OpenShift workloads.

There are two variations:

2.1.1 QuickStart

• Fast deployment

• Designed for demo, POC, development

• Simplified architecture

• Not meant for full production

• Lower compliance strictness

Useful when:

• You need a quick test environment

• You want to validate app compatibility

• You want to show cloud-native functionality

2.1.2 Standard (Production Version)

• Fully compliant

• Designed for regulated workloads

• Follows Financial Services reference architecture

• Includes:

  • Private subnets

  • Strong network boundaries

  • Centralized logging

  • Key management

  • IAM policies

  • Flow logs

  • Activity Tracker

  • Secure OpenShift configuration

This is the version required for real financial production workloads.

In exam questions:
If they ask for a “production-ready, compliant OpenShift environment,”
the answer is:

“Landing Zone for OpenShift – Financial Services edition (Standard).”

2.2 Landing Zone modules with Terraform

IBM offers Terraform modules to deploy:

• Compliant VPCs

• Secure subnets

• IAM policies

• Flow Logs

• Activity Tracker

• Key Protect

• Optional Edge VPC

• Routing configurations

Terraform-based landing zones:

• Speed up deployment

• Ensure reproducible configuration

• Reduce human error

• Automatically implement early-stage compliance controls

• Are essential for large-scale, multi-account deployments

In exam contexts, if the question mentions:

• “Automation”

• “Infrastructure-as-code (IaC)”

• “Consistent deployment”

• “Secure-by-default foundation”

The correct answer is usually:

“Use IBM Cloud Landing Zone Terraform modules.”

3. Network & Security Architecture

This is one of the most exam-heavy topics.
Financial workloads require extremely strong network isolation and security.

3.1 Multi-zone VPC design

A zone is like a separate physical area inside a cloud region.
Using multiple zones helps protect against zone-level failures.

Financial workloads often require:

• High availability (HA)

• Fault tolerance

• Zero downtime

A multi-zone design ensures:

• If Zone A fails, Zone B still runs

• Services stay online

• Customer impact is minimized

In IBM Cloud VPC, multi-zone designs apply to:

• Load balancers

• VSIs

• OpenShift clusters

• Databases

Exam questions often refer to:

• "Resilient design"

• "Availability requirements"

• "Mission-critical workloads"

→ the answer: multi-zone VPC.

3.2 Network segmentation

Segmentation divides networks into separate areas.

Financial workloads need segmentation to:

• Prevent lateral movement during attacks

• Limit the blast radius of incidents

• Meet regulatory isolation requirements

• Apply least-privilege network access

Typical subnet types:

3.2.1 Public subnets

• Only for internet-facing workloads

• Must be tightly controlled

• Usually placed in an Edge VPC

3.2.2 Private subnets

• For internal workloads

• No direct internet access

• Access via NAT or private endpoints

3.2.3 Management subnets

• For admin tools

• Restricted access

• Protected by IAM + CBR + VPN/Direct Link

3.3 Ingress / egress patterns

3.3.1 Ingress (incoming traffic)

• Public-facing endpoints should be in an Edge VPC

• Traffic flows through:

  • Load balancers

  • Firewalls

  • WAF (if needed)

This prevents unauthorized direct access.

3.3.2 Egress (outgoing traffic)

Outbound traffic must be controlled:

• To avoid data exfiltration

• To enforce compliance rules

• To prevent apps from reaching unapproved endpoints

Common methods:

• Private endpoints

• Egress allow lists

• NAT gateways

• CBR restrictions

3.4 Zero-trust elements

Zero-trust means:

“Never trust by default. Always verify. Apply least privilege everywhere.”

Key concepts:

3.4.1 Strong identity

• IBM Cloud IAM

• Service ID

• API keys

• Access groups

• Role-based access control (RBAC)

3.4.2 Multi-factor authentication (MFA)

• Essential for privileged access

• Reduces credential-based attacks

3.4.3 Fine-grained roles

• Granular permissions

• Only allow access necessary for job functions

3.4.4 Context-based restrictions (CBR)

• Restrict access based on:

  • Source network

  • IP address

  • Region

  • Service identity

CBR is a major exam topic.

4. Data Security & Key Management Design

Financial workloads process extremely sensitive data.
This section ensures data confidentiality, integrity, and compliance.

4.1 Key management services

Two main IBM services:

4.1.1 IBM Key Protect

• Cloud-based key management

• Good for most workloads

• Supports:

  • Key rotation

  • Key import

  • Key policies

4.1.2 Hyper Protect Crypto Services (HPCS)

• HSM-backed

• Uses FIPS 140-2 Level 4 hardware

• Strongest security IBM offers

• Provides customer-controlled keys (CCK)

• Prevents IBM from accessing customer keys

In regulated workloads, exam questions often favor HPCS.

4.2 Encryption design

4.2.1 Encryption at rest

Required for:

• Block storage

• File storage

• Databases

• Object Storage

• Cluster storage

Usually implemented with:

• IBM Key Protect

• HPCS

4.2.2 Encryption in transit

Use:

• TLS for internal/external connections

• Private endpoints

• VPN or Direct Link for on-prem access

4.3 Alignment with regulatory and internal policies

Regulators often require:

• Customer-managed encryption keys

• Periodic key rotation

• Validation of encryption algorithms

• Separation of duties

• Auditability

Internal policies may specify:

• Minimum encryption strength

• Mandated HSM usage

• Logging requirements

You must design encryption that satisfies both.

5. Resiliency & Performance Design

Financial systems must stay available even during failures.

This section corresponds to:

• SLO/SLA requirements

• Risk classifications

• Business impact assessments

5.1 Availability strategies

5.1.1 Multi-zone

Protects against zone-level outages.
Recommended for nearly all regulated workloads.

5.1.2 Multi-region

Protects against regional failures.
Used for:

• Disaster recovery

• High-impact workloads

5.1.3 Active-active

• Both regions serve traffic simultaneously

• Zero-downtime failover

• More complex and expensive

5.1.4 Active-standby

• Standby region is idle or partially active

• Lower cost

• Higher RTO

5.2 Recovery objectives

5.2.1 RTO (Recovery Time Objective)

• How long the system can be down

• Lower RTO → more complex architecture

5.2.2 RPO (Recovery Point Objective)

• How much data loss is acceptable

• Zero RPO requires synchronous replication

Critical financial workloads often demand:

• RTO < minutes

• RPO ≈ zero

5.3 Disaster recovery (DR)

Components include:

• DR region

• Backup and restore strategy

• Database replication

• Failover automation

• Periodic DR testing

Regulators require:

• Documented DR plans

• DR test evidence

• Clear responsibilities

Architectures must align with:

• SLAs

• Regulatory expectations

• Internal risk classification

Technical Solution Design (Additional Content)

1. Control-to-Architecture Mapping

1.1 Mapping Controls to Technical Components

A compliant architecture must draw a clear line between each required control and the architectural element that satisfies it. This ensures that the solution design directly reflects regulatory expectations. Examples include mapping:

• Network isolation controls to VPC segmentation and ACL structures

• Encryption controls to key management services and encrypted storage

• Identity controls to IAM roles and CBR policies

• Audit controls to Activity Tracker and centralized logging pipelines

This mapping step is essential for demonstrating compliance during design reviews, audits, and regulatory inspections.

1.2 Inherited Controls vs Customer-Implemented Controls

Platform services provide inherited compliance features such as physical security, hypervisor protection, or default encryption. However, the customer must still implement workload-specific controls, including:

• Application-level access rules

• Encryption key ownership and lifecycle decisions

• Logging configuration for their workloads

• Data classification and retention policies

Solution designs must clearly distinguish between inherited platform controls and customer-owned controls.

1.3 Architecture as a Compliance Mechanism

Many compliance requirements can be satisfied through specific architecture choices. For example:

• Using multi-zone VPCs to meet availability and resilience controls

• Using HPCS to satisfy strict key custody requirements

• Using private endpoints to satisfy “no public internet exposure” regulations

Architectural decisions are therefore part of the compliance story, not just technical design.

2. Architectural Guardrails

2.1 Enforcing Secure Defaults

Guardrails apply automated policies that enforce secure-by-default configurations, such as:

• Mandatory encryption for all storage

• Mandatory logging for all workloads

• Denial of non-approved network exposure

Guardrails prevent accidental misconfigurations that would violate regulatory expectations.

2.2 Blocking Non-Compliant Patterns

Guardrails prevent the creation of resources or configurations that fail security or compliance checks. These may include:

• Disallowing unencrypted object storage

• Blocking insecure security group rules

• Restricting deployment of services not on the eligible list

This ensures architectural consistency across teams and environments.

2.3 Consistency Across the Organization

Guardrails apply to all environments, accounts, and workloads, ensuring consistent adherence to:

• IAM principles

• Network isolation

• Logging and monitoring baselines

• Encryption standards

This uniformity is essential for highly regulated organizations with large scale cloud adoption.

3. Service Eligibility and Validation Requirements

3.1 Eligible Services

Eligible services are those approved for use in financial regulated workloads. They meet baseline requirements but have not undergone deep validation.

3.2 Validated Services

Validated services undergo detailed compliance assessments that confirm:

• Secure configuration options

• Alignment with control framework requirements

• Availability of audit documentation

• Strict lifecycle and update processes

• Proper support for encryption, logging, IAM, and network controls

Validated services are a subset of eligible services.

3.3 Service Usage Restrictions

Services not listed as eligible cannot be used for regulated workloads under any circumstances, even if they appear technically suitable. This prohibition protects customers from compliance risk.

4. IAM Architecture and Privileged Access Design

4.1 Least-Privilege Access and Segregation of Duties

IAM architecture must enforce:

• Roles with minimal permissions

• Separate administrative domains for production and non-production

• Clear separation between security, operations, and development teams

Separation of duties is a regulatory expectation.

4.2 Privileged Access Requirements

Administrative access must meet strict standards:

• Multi-factor authentication (MFA)

• Access from approved networks only

• Logging of all privileged actions

• Time-bound or just-in-time privileges for sensitive operations

4.3 Federated Identity

Enterprises typically use centralized identity providers such as Active Directory or LDAP. Federated IAM ensures:

• Centralized authentication policy enforcement

• Unified identity lifecycle management

• Consistent MFA and password policies

4.4 Break-Glass Access

A controlled emergency-access process must exist, covering:

• Temporary elevation

• Full logging and justification

• Post-event review

This is a regulatory requirement for operational resilience.

5. Logging and Monitoring Design Requirements

5.1 Mandatory Logging Sources

Regulated workloads must produce logs including:

• IAM activity logs

• API audit logs

• Network flow logs

• System logs for compute, storage, and containers

• Application logs

These logs support compliance, forensics, and monitoring.

5.2 Centralized SIEM Integration

Logs must be forwarded to centralized SIEM platforms where:

• Correlation with on-prem and multi-cloud events occurs

• Alerts support detection of security incidents

• Regulatory and audit reporting is generated

5.3 Log Retention Requirements

Retention periods are dictated by regulatory and internal requirements. Log retention must be:

• Tamper-resistant

• Auditable

• Accessible to security and compliance teams

Retention periods can span several years depending on jurisdiction.

6. Data Protection Enhancements

6.1 Protection in Non-Production

Sensitive data used for testing or development must be:

• Masked

• Tokenized

• Pseudonymized

Regulated data cannot be used unmodified in non-production environments.

6.2 Data Minimization Principles

Data sharing across systems must follow minimization principles:

• Collect and retain only what is required

• Limit exposure to the minimum necessary fields

• Avoid unnecessary replication

This reduces risk and aligns with privacy regulations.

6.3 Trust Boundaries

Data must remain within approved trust boundaries, which are defined by:

• VPC segmentation

• Encryption boundaries

• Identity governance

• Regional residency requirements

Crossing trust boundaries triggers additional control requirements.

7. Secure CI/CD Pipeline Architecture

7.1 Mandatory Security Gates

Pipelines must include:

• Static code analysis

• Dependency scanning

• Image vulnerability scans

• Infrastructure-as-code policy checks

These ensure the system remains secure as it evolves.

7.2 Image Signing and Verification

Container images must be signed and verified before deployment. This prevents the use of compromised or unauthorized images.

7.3 Zero-Trust Pipeline Operation

Build and deployment systems must follow:

• Isolated build runners

• Minimal privileges

• Controlled secrets management

• Strict network restrictions

This prevents pipeline compromise, which is a major attack vector.

8. Resilient Connectivity Architecture

8.1 Redundant Connectivity for Mission-Critical Systems

Critical workloads require:

• Dual Direct Link circuits

• Independent network paths

• Failover routing policies

This protects against connectivity failures.

8.2 Segmented Trust Zones

Connectivity must enforce:

• Segmentation by environment (prod vs non-prod)

• Segmentation by sensitivity level

• Restricted egress routes

Segmentation prevents accidental or malicious cross-environment contamination.

8.3 Encrypted Network Paths

All traffic must remain encrypted, including:

• On-prem to cloud links

• Inter-zone traffic

• Service-to-service traffic

Encryption is a regulatory requirement.

9. Multi-Account and Environment Segregation Models

9.1 Multi-Account Segregation

Organizations should use multiple IBM Cloud accounts to isolate:

• Production workloads

• Non-production workloads

• Shared platform services

This limits the blast radius of mistakes or compromises.

9.2 Consistent Governance

Policies must apply consistently across all accounts via:

• Standard IAM frameworks

• Centralized guardrails

• Landing zone enforcement

• Shared logging standards

9.3 Separation of Duties Through Account Boundaries

Account-level separation provides strong boundaries for administrative control and auditing.

10. Security Testing and Threat Modeling Requirements

10.1 Threat Modeling for Regulated Architectures

Solution teams must perform threat modeling to identify:

• Attack surfaces

• Trust boundaries

• Potential misconfigurations

• High-risk components

This is required for regulated workloads.

10.2 Penetration Testing Requirements

Penetration tests must:

• Follow regulated testing guidelines

• Be performed under approved scopes

• Generate evidence for remediation and auditing

10.3 Continuous Vulnerability Scanning

Scanning must occur at:

• Build time (pipeline)

• Deployment time

• Runtime

This ensures continuous security posture alignment.