Topics of GCP Professional Cloud Architect exam

Go to GCP official page for more information and register for the exam.

Section 1: Designing and planning a cloud solution architecture

1.1 Designing a solution infrastructure that meets business requirements. Considerations include:

• business use cases and product strategy
• cost optimization
• supporting the application design
• integration
• movement of data
• tradeoffs
• build, buy or modify
• success measurements (e.g., Key Performance Indicators (KPI), Return on Investment (ROI), metrics)

1.2 Designing a solution infrastructure that meets technical requirements. Considerations include:

• high availability and failover design
• elasticity of cloud resources
• scalability to meet growth requirements

1.3 Designing network, storage, and compute resources. Considerations include:

• integration with on premises/multi-cloud environments
• identification of data storage needs and mapping to storage systems
• data flow diagrams
• storage system structure (e.g., Object, File, RDBMS, NoSQL, New SQL)
• mapping compute needs to platform products

1.4 Creating a migration plan (i.e., documents and architectural diagrams). Considerations include:

• integrating solution with existing systems
• migrating systems and data to support the solution
• licensing mapping
• network and management planning
• testing and proof-of-concept

1.5 Envisioning future solution improvements. Considerations include:

• cloud and technology improvements
• business needs evolution
• evangelism and advocacy

Section 2: Managing and provisioning solution Infrastructure

2.1 Configuring network topologies. Considerations include:

• extending to on-premises (hybrid networking)
• extending to a multi-cloud environment
• security
• data protection

2.2 Configuring individual storage systems. Considerations include:

• data storage allocation
• data processing/compute provisioning
• security and access management
• network configuration for data transfer and latency
• data retention and data lifecycle management
• data growth management

2.3 Configuring compute systems. Considerations include:

• compute system provisioning
• compute volatility configuration (preemptible vs. standard)
• network configuration for compute nodes
• orchestration technology configuration (e.g. Chef/Puppet/Kubernetes)

Section 3: Designing for security and compliance

3.1 Designing for security. Considerations include:

• Identity and Access Management (IAM)
• data security
• penetration testing
• Separation of Duties (SoD)
• security controls

3.2 Designing for legal compliance. Considerations include:

• legislation (e.g., Health Insurance Portability and Accountability Act (HIPAA), Children’s Online Privacy Protection Act (COPPA), etc.)
• audits
• certification (e.g., Information Technology Infrastructure Library (ITIL) framework)

Section 4: Analyzing and optimizing technical and business processes

4.1 Analyzing and defining technical processes. Considerations include:

• Software Development Lifecycle Plan (SDLC)
• continuous integration / continuous deployment
• troubleshooting / post mortem analysis culture
• testing and validation
• IT enterprise process (e.g. ITIL)
• business continuity and disaster recovery

4.2 Analyzing and defining business processes. Considerations include:

• stakeholder management (e.g. Influencing and facilitation)
• change management
• decision making process
• customer success management

4.3 Developing procedures to test resilience of solution in production (e.g., DiRT and Chaos Monkey)

Section 5: Managing implementation

5.1 Advising development/operation team(s) to ensure successful deployment of the solution. Considerations include:

• application development
• API best practices
• testing frameworks (load/unit/integration)
• data and system migration tooling

5.2 Reading and writing application development languages. At a minimum, languages include:

• Java
• Python

Section 6: Ensuring solution and operations reliability

6.1 Monitoring/Logging/Alerting solution

6.2 Deployment and release management

6.3 Supporting operational troubleshooting

6.4 Evaluating quality control measure

Distributed tracing with Spring Cloud Sleuth

Spring Cloud Sleuth

https://cloud.spring.io/spring-cloud-sleuth/

How to use it

For simple use-case all we need to do is to have Sleuth as dependency in Spring boot project

Maven

<dependencyManagement>         <dependencies>             <dependency>                 <groupId>org.springframework.cloud</groupId>                 <artifactId>spring-cloud-dependencies</artifactId>                 <version>Edgware.RELEASE</version>                 <type>pom</type>                 <scope>import</scope>             </dependency>         </dependencies> </dependencyManagement> <dependencies>     <dependency>         <groupId>org.springframework.cloud</groupId>         <artifactId>spring-cloud-starter-sleuth</artifactId>     </dependency> </dependencies>

Or 

Gradle

dependencyManagement {      imports {           mavenBom 'org.springframework.cloud:spring-cloud-dependencies:Edgware.RELEASE'      } } dependencies {     compile 'org.springframework.cloud:spring-cloud-starter-sleuth' }

Log format

Since we only output the log to the console then default Spring boot log format and configuration is good enough.

<conversionRule conversionWord="clr" converterClass="org.springframework.boot.logging.logback.ColorConverter"/>     <conversionRule conversionWord="wex" converterClass="org.springframework.boot.logging.logback.WhitespaceThrowableProxyConverter"/>     <conversionRule conversionWord="wEx" converterClass="org.springframework.boot.logging.logback.ExtendedWhitespaceThrowableProxyConverter"/>     <property name="CONSOLE_LOG_PATTERN"               value="${CONSOLE_LOG_PATTERN:-%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}"/>

With Sleuth the log looks like bellow

2017-12-01 12:06:42.651  INFO [jpa.demo,0000001234567879,0000000123456789,true] 34765 --- [nio-8080-exec-1] com.springjpa.controller.WebController   : Done

[jpa.demo,0000001234567879,0000000123456789,true] part is added by Sleuth, the format is [appname,traceId,spanId,exportable] 

• spanId - the id of a specific operation that took place
• appname - the name of the application that logged the span
• traceId - the id of the latency graph that contains the span
• exportable - whether the log should be exported to Zipkin or not. When would you like the span not to be exportable? In the case in which you want to wrap some operation in a Span and have it written to the logs only.

Within Spring Boot projects, adding the Spring Cloud Sleuth library to the classpath will automatically add 2 HTTP headers to all calls:

• X-B3-Traceid Shared by all HTTP calls of a single transaction i.e. the wished-for transaction identifier

• X-B3-Spanid Identifies the work of a single microservice during a transaction

Non-Spring Boot app may need to handle these 2 headers itself.