Assessment

Chapter 1: Monolithic versus Microservices

1. True – Microservices are difficult to test due to their distributed nature.
2. False – Monolithic applications belong to static infrastructures, while microservices belong to dynamic infrastructures.
3. True – When a monolithic application becomes too big, its benefits start to disappear.
4. True – Debugging becomes difficult due to its distributed nature.
5. True – Due to tight interdependencies, monolithic applications are difficult to maintain and patch in the long-term.

Chapter 2: Cloud-Native Applications

1. True – Kubernetes allows different runtimes for containers.
2. False – Due to the independent size of microservices, cloud-native applications are simpler than monolithic applications but difficult to test.
3. True – Without tools, it is difficult to diagnose cloud-native applications.
4. True – Apache Mesos does much more than Kubernetes, but Kubernetes excels in container orchestration compared to Mesos.
5. True – Due to its large community and support for a variety of features, Kubernetes has become the de-facto container orchestration system.

Chapter 3: Service Mesh Architecture

1. True – The service mesh is an abstract layer on top of applications.
2. False – Sidecar proxies live next to a microservice, mainly in the data plane. However, system components in a control plane may also have associated sidecars.

3. True – The service mesh is like an abstract application layer on top of the application stack and provide a L7 traffic management, security, and observability.

Chapter 4: Service Mesh Providers

1. True – At the time of writing, Istio and Linkerd are available in Kubernetes. Istioctl can run in a VM environment for integration but it doesn't have good adoption rates.
2. False – Linkerd developed its own sidecar proxy written in Rust, whereas Istio and Consul use the Envoy sidecar, which is developed by Lyft.
3. False – The non-availability of a control plane will not stop sidecar-enabled microservices from functioning, though some capabilities may not be available.

Chapter 5: Service Mesh Interface and SPIFFE

1. True – SPIFFE is a specification and not a toolset, similar to Kubernetes' Container Network Interface (CNI), Container Storage Interface (CSI), and Container Runtime Interface (CRI).
2. False – The service mesh interface is a specification that service mesh providers can use to provide interoperability.
3. True – At the time of writing, Istio and Consul use SPIFFE.
4. True – Istio developers produced their own SPIFFE implementation instead of using SPIRE.

Chapter 6: Building Your Own Kubernetes Environment

1. A). Apache Mesos is not a Kubernetes platform.
2. False – Kubernetes can be deployed in many environments, including a simple VM.
3. True – A Kubernetes cluster is meant for container-based applications.

4. True – Kubernetes services can be used to register a monolithic application to provide integration between cloud-native applications hosted in Kubernetes and monolithic applications outside Kubernetes.
5. False – It is simple to build your own Kubernetes cluster.

Chapter 7: Understanding the Istio Service Mesh

1. Layer 7 – This is the network layer that the service mesh works on.
2. All of the above.
3. False – The Istio control plane is not a single point of failure since applications can continue to run without a control plane,
4. True – A true service mesh is formed through a data plane where there's an Envoy sidecar proxy next to each microservice, which helps achieve service mesh functions.
5. False – Istio can span multiple Kubernetes clusters through a replicated control plane, a shared control plane using a single network and a shared control plane using a multi-network.
6. True – At the time of writing, Istio service discovery integration with Consul is in its alpha phase.
7. False – This should be the other way around. Pilot pushes configuration to Envoy, which manages traffic.
8. False – Istio...

Chapter 8: Installing a Demo Application

1. True – Kubernetes provides its own DNS server.
2. Polyglot application – Each microservice can use its own language.
3. True – The service mesh architecture is only for microservice applications.

4. False – A pod's IP address can change when it is redeployed/rescheduled.
5. True – For the duration of the service, its IP address is immutable.
6. True – The service's IP address is linked to the pod's IP address through Kubernetes endpoints.

Chapter 9: Installing Istio

1. True – At the time of writing, Istio can only be used in a Kubernetes environment, though integration with VMs is being planned.
2. False – The Istio sidecar can be enabled for new applications if the namespace is annotated with the istio-injection=enabled label. The sidecar can be enabled through the istioctl command.
3. True – Istio has more than 57 CRDs.
4. True – It is necessary to install CRDs to extend Kubernetes so that it can use Istio's features.
5. True – The existing application needs to be taken down first and then you need to enable sidecar proxy injection, either by annotating the namespace with a label or by using istioctl kube-inject to modify the existing application's manifest.
6. False – It is possible to disable the sidecar for a microservice by setting the pod annotation to sidecar.istio.io...

Chapter 10: Exploring Istio Traffic Management Capabilities

1. True – Traffic routing is a feature of Envoy, which receives its configuration from Pilot.
2. True – Istio can work in a zero-trust network and still provide enterprise-grade security.
3. True – You can enable a reverse firewall in Istio through an Egress gateway, which will block outbound access from microservices.

4. True – Dark launches/Family-and-Friend Testing is used to route traffic to select groups of users without their knowledge.
5. True – An Istio gateway can have multiple virtual services that can be used by different application owners.
6. True – Istio's virtual service is a superset of a Kubernetes service since it provides more features and functions than its native service.
7. True – The destination rule defines the configuration, but it has no role in traffic routing...

Chapter 11: Exploring Istio Security Features

1. True – It is the end user's responsibility to rotate certificates and keys that have been defined for the Ingress gateway in order to secure traffic from external clients and send it to the edge microservice. Note that Istio's Citadel rotates certificates for microservices.
2. True – There can only be one MeshPolicy (with name as the default) that will apply mTLS mesh-wide.
3. True – Mutual TLS can be as granular as possible from the namespace level to the service level by defining a policy.
4. True – Mutual TLS can be enabled through destination rules or by using MeshPolicy.
5. True – Istio is capable of shielding modern microservices applications from running in a zero-trust network without any changes needing to be made to the application code.
6. True – Istio makes VPNs and firewalls redundant...

Chapter 12: Enabling Istio Policy Controls

1. False – Quota assignment to services is enforced through Mixer.
2. True – Rate limits to services are pushed down to the Envoy proxy through Mixer.
3. True – A list checker handler is assigned a list of source IPs to create a list. A source IP instance list entry is created to check the IP address that was found at the Ingress gateway. A rule can be created to enforce a blacklist or whitelist for IP addresses that can connect to the service.
4. True – To enable policy enforcement, you can edit the Istio config map and set disablePolicyChecks=true.

Chapter 13: Exploring Istio Telemetry Features

1. True – A sidecar proxy sends asynchronous telemetry data to backend services.
2. False – Observability and monitoring a system are two different things.
3. True – The recommended web UIs for Istio's monitoring and observability features are Grafana, Prometheus, Kiali, and Jaegar.
4. False – Port forwarding is not the only way to access different web UI components. Ingress rules and node port mechanisms can also be used to access a web UI.
5. True – Istio reports multiple spans within a microservice chain.
6. True – Prometheus is a web UI tool that can visualize collected data or metrics.
7. True – Custom dashboards in Grafana provide details for inbound and outbound workloads.
8. True – All mis-configurations are highlighted in red under the YAML viewer in Kiali.

...

Chapter 14: Understanding the Linkerd Service Mesh

1. True – Linkerd has an automatic protocol and TCP connection detection.
2. False – Linkerd does not provide its own ingress controller.
3. False – The Linkerd proxy is written in Rust, while control plane components are written in Go.
4. True – The control and data planes can be in a single namespace if we want them to be. Note that admin privileges are required to create CRDs.
5. True – When a Linkerd proxy is injected into a running pod using the linkerd inject command, the pod is restarted automatically.
6. False – The pod will be recreated if we want to add a debug sidecar.
7. True – The retry budget helps us avoid a retry storm. We don't need to configure Linkerd to achieve this.
8. True – For automatic sidecar injection, Istio needs a namespace to be labeled with istio-injection=enabled...

Chapter 15: Installing Linkerd

1. False – You do not need SSH access to the master node to create the Linkerd control plane.
2. True – You require a cluster-admin role to install control plane configuration.
3. False – You do not require a cluster-admin role to install the control plane.
4. False – You need to annotate a namespace, not a label, with linkerd.io/inject: enabled.
5. False – You need to annotate the pod with linkerd.io/inject: disabled to exclude it from getting the sidecar proxy.

Chapter 16: Exploring the Reliability Features of Linkerd

1. True – Kubernetes does load balancing at the connection level (L4).
2. True – Linkerd does load balancing at the application level (L7).
3. True – Linkerd's load balancing is out of the box and requires zero configuration.
4. True – Retrying Linkerd requires a configuration-patch service profile with isRetryable: true.
5. True – A Linkerd service profile can be generated automatically, even if the Swagger API isn't available for the service through the Linkerd profile command.
6. True – The retry budget is about adaptive retries instead of a fixed number of retries.
7. True – The service profile is needed to provide aggregated route metrics.

Chapter 17: Exploring the Security Features of Linkerd

1. True – The TLS between service-to-service communication is fully automatic in Linkerd.
2. False – The TLS between the Ingress gateway and the edge service of the application is the application user's responsibility.
3. True – The linkerd-identity component of Linkerd's control plane is the Certificate Authority (CA) for the data plane proxies.
4. True – The linkerd-identity component automatically rotates the certificates for linkerd-proxy in the data plane.
5. False – The linkerd-identity component doesn't automatically rotate certificate for its own CA.
6. True – You can use trusted certificates from your own CA for linkerd-identity, but only at the time of install.
7. True – You can change the trusted certificate of the control plane at any time, but it requires reinstalling...

Chapter 18: Exploring the Observability Features of Linkerd

1. True – Linkerd only stores data for 6 hours. This can be configured so that we can increase or decrease the time limit.
2. True – Linkerd provides distributed tracing, which can be seen from the dashboard as well as through the CLI tap command.
3. True – Linkerd integration with the external Prometheus is the user's responsibility.
4. True – Linkerd's Prometheus uses the Pull model to collect data from service proxies.

Chapter 19: Understanding the Consul Service Mesh

1. False – Consul is a distributed control plane.
2. True – The Consul agent must run on all Kubernetes nodes.
3. True – Consul services can be viewed as North-South network traffic, whereas Ingress gateways to multiple Kubernetes clusters can be treated as East-West network traffic.
4. False – The Mesh gateway does not decrypt network traffic between two gateways to determine the destination service.
5. True – Consul service discovery in a Kubernetes environment is automatic.
6. True – Consul supports multiple data centers out of the box.

Chapter 20: Installing Consul

1. True – Consul's service mesh works across heterogeneous environments and data centers across different regions.
2. True – In a Consul cluster, the Consul servers can be in Kubernetes or in VMs.
3. False –The Consul members can join an existing Consul cluster from a VM or Kubernetes.

4. False – Consul servers remain within the same data centers but they can communicate with other data center. Consul servers use the WAN protocol.
5. True – Kubernetes can send write requests to any Consul servers, but only the leader Consul server writes that information to the distributed key-value store.
6. False – Consul uses its own key-value database store to maintain the state of Consul clusters. It doesn't use Kubernetes etcd.

Chapter 21: Exploring the Service Discovery Features of Consul

1. False – Consul Connect is the service mesh for Kubernetes, as well as VMs.
2. False – Consul Connect uses sidecar proxies for services in a Kubernetes environment.
3. True – Consul Intentions are authorizations for services.
4. True – Consul's K/V store is replicated across data centers automatically.
5. True – Consul mTLS from a sidecar proxy to another sidecar proxy is fully automatic.
6. True – Consul comes with its own Certificate Authority so that it can issue certificates to sidecar proxies.
7. True – Consul integration with Kubernetes for service discovery is done by defining a Consul DNS server as an upstream DNS in the Kubernetes CoreDNS configuration.

Chapter 22: Exploring Traffic Management in Consul

1. True – Consul traffic management is done at Layer 7 of the Open System Interconnection (OSI).
2. True – The service-resolver definition that's used to declare subsets is based on filters that are used on the metadata of the services. In Kubernetes deployments, such metadata is picked up automatically by Kubernetes through its integration to Consul.
3. True – The Mesh gateway mode is akin to the Egress gateway.

4. True – If service-defaults defines a Mesh gateway mode as being local, each call is made to the Mesh gateway to determine the upstream service.
5. True – Traffic routing using a service-router can only be used for path-based routing.
6. True – Service-resolver can be used to provide a service failover from one data center to another.