S90.09 Sample Questions & Answers

The diagram shows a direct 'Deploy to Production' step. To achieve zero-downtime and fast rollback, a progressive deployment strategy is needed. A canary deployment would release the new version to a small subset of users first, while a blue-green deployment would deploy the new version to a parallel production environment. Both allow for validation in a live environment before a full cutover and provide an immediate rollback path by simply redirecting traffic back to the old version. This stage is essential for mitigating deployment risk.

URI versioning is a common and clear method for supporting multiple, potentially breaking, versions of a service concurrently. This allows existing consumers to continue using the older, stable version (v1) while new consumers can adopt the new version (v2). It gives consumers control over their migration timeline, preventing the service evolution from breaking them and thus achieving the primary goal.

Serverless (FaaS) platforms are ideal for spiky, event-driven workloads. The key benefits that match the requirements are the 'scale-to-zero' capability, which means no resources are consumed and no costs are incurred during idle periods, and the automatic, massive scaling in response to event bursts. This directly addresses the cost optimization and scalability requirements more effectively than a Kubernetes cluster, which would require a minimum number of nodes to be running continuously.

Aggregating logs from all services into a single, searchable platform (like the ELK stack or Splunk) is the first step to being able to analyze behavior across the entire system.

This is crucial for understanding the path of a request as it travels through multiple services. By propagating a unique correlation ID, tracing tools (like Jaeger or Zipkin) can visualize the entire call graph and pinpoint latency in specific downstream services.

Collecting time-series metrics (like request latency, error rates, resource utilization) from each service and visualizing them in dashboards (using tools like Prometheus and Grafana) allows the team to spot anomalies and correlate performance degradation with system events.

When services are composed synchronously, their availabilities are multiplied to calculate the composite availability. The aggregator service is only available if BOTH Service A AND Service B are available. Therefore, the composite availability is calculated as: 0.995 * 0.990 = 0.98505, or 98.505%. This demonstrates how synchronous dependencies in a service composition decrease overall availability.

A Bounded Context is a core pattern in DDD that defines the boundary where a specific domain model applies. Inside this context, terms and concepts have a precise, unambiguous meaning (the ubiquitous language). This makes it a natural and effective boundary for a microservice, ensuring the service has a clear, well-defined responsibility and a consistent internal model.

This is the correct definition of a multi-stage build. It uses one or more intermediate stages to perform build-time tasks, leveraging images that contain compilers and other tools. The final stage starts from a clean, minimal base image and copies only the necessary runtime artifacts from the previous stages. This ensures the final image contains only the application and its runtime dependencies, drastically reducing its size and attack surface by excluding all build tools.

A distributed configuration store is designed specifically for this purpose. Tools like Consul's Key-Value (KV) store or etcd provide a centralized, highly available location to store configuration data. Services can watch for changes and update their configuration dynamically, and these systems typically offer versioning or an audit trail of changes.

The Adapter pattern is the ideal solution. It involves creating a dedicated service or component that acts as a translator between the modern REST/JSON world and the legacy binary protocol. This new adapter service exposes a clean, modern REST API to the other microservices and encapsulates all the complexity of dealing with the legacy system. This prevents the legacy protocol logic from 'corrupting' the design of the new microservices, hence it's also known as an Anti-Corruption Layer.

WS-Security operates at the Application Layer (Layer 7). It provides message-level security by embedding security information (like signatures and encryption details) directly within the SOAP message header. This is distinct from transport-level security (like TLS/SSL), which operates at a lower layer and only protects the communication channel.